Mr Ekted

I said it was incomplete, and only in a trivial way. You could have fixed your code in less time than it took you to write that paper. Let's just illustrate the 3 cases with specific examples. I am the client. I receive a position packet with a 16-bit timestamp that actually resolves to a true 32-bit timestamp. At the point that I receive the packet I need to use the server time (that I think it is) to determine the upper 16-bits. (let's just drop all the one-way and two-way latency stuff as it just clouds the issue) 0x0000ffff sent as 0xffff received at 0x00010008 becomes 0x0000ffff (-1) 0x00010001 sent as 0x0001 received at 0x0000ffff becomes 0x00010001 (+1) 0x00000fff sent as 0x0fff received at 0x00001008 becomes 0x00000fff (0) How likely any case is to happen is irrelevant. They all CAN happen, and it's trivial to account for them. Btw, the discussion with Snrrrub about this issue which occurred many months ago, was not an attempt to poke at MERV in any way. I was just passing on something that I thought was incorrect. In the end, we agreed to disagree.

No, it's a problem with the S2C position packets coming TO the bot. What's gained is 2 less bytes in the position packet. What do you mean by your word string? There are no strings in the position packets, just bytes, words, and dwords.

The ability to shoot from anywhere, even the delays inherent in shooting all the various weapons and specials, is all up to the client. So a custom client (eg a bot) can shoot whatever it likes as often as it likes and from any location (even from inside a wall). Note that the server DOES check that the weapons/specials you are shooting are valid for your known ship+upgrades, and there's also some flood checking.

I was wondering when someone would ask. It's the code to infer the upper 2 bytes of the timestamp from the player position packets. If you get a timestamp of say 0x1234 and you know the current server time should be 0x55551241, then you can infer the packet timestamp is 0x55551234. There are 2 other much-less-common cases, where the packet timestamp is wrapped ahead or behind. When last I looked, MERV only handled one of them--I forget which. I discussed it with Snrrrub--who I believe ripped most of the VIE source that Catid needed--and he disagreed with me. The argument led to a complete breakdown of propriety between us (which I regret). It's a very small point, but can cause wildly out-of-sync position packets in the bot every 65536 SS ticks (655 seconds), which any decent core/client should simply drop. Visually, there would be one missing packet, so it would not result in anything noticable. Again, it is a very small point.

Yes, but it is expected that the client clock run at the same speed as the server clock. This can be seen by sysops using the *tinfo command. If the times stray too far apart or spike, the client can be specced or booted. Also, I think Cont itself checks for "speedhack" although I don't know a thing about how it would do this.

If you need me to post a picture to show you that there's a specific file I have named that is missing from your server, you are an idiot. http://home.maine.rr.com/user/ekted/ssf.jpg

And I get X's in place of the icon in the forum lists. Fix it!

http://www.ssforum.net/style_images/1/icon19.gif

Are your images 8-bit? The defaults are all 8-bit and use the SS palette.

Meaning it wasn't fastened down properly?

The only requirement for replacing the default bm2 files is that the layout of the sub-images be the same as the original. A ship(x).bm2 file has 10x4 sub-images. Ships.bm2 (all 8 ships) has 10x32 sub-images. The one thing I'm not positive about is if the replacement images need to have the same proportion as the original. You should try shrinking the images so that each ship sub-image fits exactly in a square cell. The defaults are 36x36 pixels.

Can you monitor the heat while playing Cont? 90C is within the operating limit for non milspec or specialized chips.

So, to actually answer your question... The SS protocol uses the value of GetTickCount()/10 for all its timestamps. GetTickCount() is a windows kernel function that gets the number of milliseconds since the machine was booted. In all cases, this value is the SERVER'S time for packets in both directions, except in the C2S 0005 client sync packet. In packets that use a 16-bit timestamp, the lower 2 bytes of the server time is used. The receiver must infer the upper 2 bytes. [Note that Catid's code does this incorrectly.] The 0005/0006 packet exchange is how the client estimates the current time on the server for events that require a timestamp. In a simple chat client, you will likely not need to handle the S2C 0006 packet.

Are you using software emulation? Try using 8-bit gfx if you current have it set to something higher. Try using a lower resolution. Bring up task manager, click on Performance tab, and go full screen in Cont for a minute. Then alt-tab back to task manager and see how high the peaks are. Try the same thing in windowed mode.

The main EXE checks that the menu[xxx].dll file is unmodified.

PriitK wouldn't even fix the prox bug problem which was plaguing so many zones until he got sex from Ghost Ship.

The profile code checks for a lot of criteria for invalid names. Apparently I missed this one. I will find out the rules and fix it for next version.

Sounds like you have a firewall blocking important ports. Directory server access uses UDP port 4990.

If a kid comes to you with a toolbox and a pile of wood and says "I'm going to build a skyscraper. What do I do?", what are you going to tell him? "Maybe you better take some engineering courses first." That's about the most constructive thing I can say.

Maybe you should understand the protocol better before you start. Your question about timestamps shows you are far from being able to proceed.

One of the differences between SS/Cont and all the aforementioned games is that SS/Cont uses DirectDraw, and the rest use Direct3D. Dunno how significant that is. Have you run all the tests in dxdiag?

Maybe for you. I get 1-2%. I do too if I alt tab then go to task manager. Have cont running up on the screen in windowed mode and open up task manager right next to it. Yes. I'm not a re-*BAD WORD*-.

Maybe for you. I get 1-2%.

I just tested this in PB. It won't score if you leave, as I expected, but it does not score when you come back.

Since balls are passed around in "real-time", the protocol for them works differently. Flags use a reliable protocol: drop, dropped, pickup, picked up. I'm not supporting this, just describing it.