Mr Ekted

Routes on the internet are not necessarily symmetric. So a one-way trace is not always what it looks like. This image shows a trace from you to the zone, with the red arrows showing the paths of the trace packets and the "error" returns. Traces to A come back through the same path, so latency and packetloss are pretty accurate. However, replies to traces to B come back through a different route. If the router C is having problems, you may get late packets or none at all, making it look like router B is not replying. The only way to get a better picture of what's going on is to have a sysop *trace you from the server as well. http://home.maine.rr.com/user/ekted/trace.jpg

There is a packet to move objects also, but there's no text command for it, so the bot has to send a binary packet for it. Does MERV support this?

After you have flooded the biller, there's quite a long delay before you can try again.

You can't make a bot of any complexity without some sort of state. The new statbox bot for PB has to keep state for over 100 digits all over the screen, and *objset commands need multiple lines.

If you have a line object at every 1 yard increment, and they are objects numbered say 100-200, then just do something like: *objset +147,-137, to turn on 147 and off 137. Note that the plus and the trailing comma are necessary. This implies that you need to remember all objects that are on. I have proposed a system of object groups within the LVZ so that you could turn on any one object and all the rest go off automatically (client side). This would solve a common problem in arenas that have extensive use of 0-9 digits for scoreboards and other data. But Priit was not interested at the time.

A bot is just a client. Basically it can only do what any sysop (or whatever mod level the bot logs in as) can do.

I don't think XP has the function OpenVxDHandle in the kernel. It may be a problem with the install program being written for Windows 98. I installed manually from the zip file.

The first method will fail. The second is correct.

You can probably set your own direction (orientation), but there's no server command to control another player's direction.

All directory servers use UDP port 4990.

The install should not be writing to kernel32.dll. Virus?

Any estimate for getting the skins back? I'm tired of these useless ones.

FYI: You can't calculate any checksums in advance. The server sends a different "keys" each time it asks for checksums. This causes the checksum formulae to generate unpredictable values each time. In other words, you can't just load an LVL, calculate it's checksum (like CRC), and store it for later.

UDP port 4990 has to be open to allow Cont to talk to the directory servers.

There are 2 checksums that change when you change arenas: level checksum, and arena settings checksum. You can tell from the server *log which of these is failing.

[insert sound of crickets here]

Thank you.

Bump. I'd like a forum mod to at least acknowledge what's going on.

Well, blank lines should not be sent.

Stop it!

Most zones do not allow them.

For #3 you'd have to make the bot spec/unspec players who attach illegally. Kind of like the way HZ changes your ship to a goalie ship if you DC and your team has no goalie already.

If the zone you are trying to connect to is on port 5000, then you need to open UDP port 5000 to play, and UDP port 5001 to see the zone pings. You also need to open UDP port 4990 to download new zones. You also need to allow ICMP to do zone trace.

In advanced options, toggle "avoid page flipping"

I can run Cont using dx 9.0b at 2048x1536