[T1]last hope/mem.dll/some kind of error - can't play

it's been happening every so often, and it seems like it'd be my ISP but some random stuff seems to fix it, and i get all sorts of error messages

i can tell something is fucked up because it takes forever to connect to a server, and if its a lasthope server i start getting that redjack box every second or so and i can't move

sometimes the same will happen and then i'll get an error message saying my flag.dts, and other random .dts's are not valid and will get me booted

other times it will say that i need to have last hope

and yet other times it will kick me and say "come back when you dont have a hacked mem.dll" or something similar

the thing is, i've replaced the mem.dll before, reinstalled lasthope, and for the obvious, no i'm not using happyflag or anything like that

i know for sure its not my skins because i get these errors randomly when i haven't changed anything, and they go away randomly as well.

i just played 11 hours ago, went to sleep, woke up, and nothing works

is this common

hackers are among us

Lag.

thanks :bigthumb:

Seriously. Lag will do that in lasthope...
Your cable modem is crapping out...

lameeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeee. sadly i'm on campus so theres nothing i can do about it, but thanks for the heads up

LastHope remote's are expected to be responded to within two seconds. There's no reason this shouldn't be possible under most normal circumstances.

ya, so WTF IS UP

Here are some things to look at.

The hacked mem.dll message you mentioned can also occur if you have an H_FOE20.BMP
file laying around.

When you play tribes its a good idea to prevent other things from running on your computer
that would tie up the cpu. If you don't have any other cheats running then you should look
for spyware or microsoft update tieing up the cpu.

On the other hand certain other cheats make excessive and unfriendly use of the available
cpu. This will tie up the cpu and prevent tribes from running enough that your client's
network traffic is disrupted.

Suppose someone had a graphical based "mid-style" autoaim that was running HaPPiLY
at 680x480. Then they go and get that new graphics card, the new monitor, and crank
the resolution way up. They still run something which is now tieing up the system even
more scanning the larger graphics memory looking for target icons.

Poor tribes is trying to talk to the server but it is getting crowded out. The game itself
is somewhat tolerant of this but the lasthope stuff is less so - it expects the response
although it does retry.

I sometimes see this effect myself with hudbot5 when the map changes. Apparently the
overhead of the map change causes hudbot5 to use a lot of cpu and this can prevent
client packets from being sent briefly - but long enough to trigger a lasthope non-response
kick. This is a rare condition and you shouldn't look here for your problem.

So go back to square 1. Remove any h_foe20.bmp file, clear out any spyware, maybe
disable automatic microsoft updates while you play, and turn off any other software that
runs along side of tribes.

bugs is the master of seeing problems where there are none, and turning molehills into mountains

it sounds like packet loss

_bugs is insane.

i am keyboard?

I doubted packetloss and thought something else was wrong yes - threw out some
ideas to check.

BTW

I had to increase the timeouts on the lasthope queries that shithole base does because
it was kicking the foreigns when the server got up to 40 players. The larger timeouts
and the 4 retries per query should mitigate a packetloss scenario.

The tribes 1 protocol is also pretty good about this kind of stuff - the delivery of the
event manager message (the lasthope response) should be in the guaranteed data
mode (see the Frohnmayer/Gift paper) - so there should have been a lot of retries
by the client.

SUPER WOOOOOOOOFER