Qndre Posted February 1, 2004 Report Posted February 1, 2004 I am writing a spec-only Continuum client. But what do I have to give if the server wants a "time-stamp"? I know it's not the CMOS time. I'll have to give a 24-bit value.
ExplodyThingy Posted February 1, 2004 Report Posted February 1, 2004 Just keep working on mgb's forums. It will be less of a headache, I promise you.
Mr Ekted Posted February 1, 2004 Report Posted February 1, 2004 Maybe you should understand the protocol better before you start. Your question about timestamps shows you are far from being able to proceed.
Grelminar Posted February 2, 2004 Report Posted February 2, 2004 Better yet, why don't you try doing some actual work on your own, rather than asking anyone who will listen to you about every little problem you come up against?
»1587200 Posted February 2, 2004 Report Posted February 2, 2004 Wow, way to attack him. Someone tries to do something for the community and all you do is put him down. Now don't think that I'm saying you three haven't, or don't do anything. Believe me, I know you do, but compared to the whole, the people that actually develop is a rather low percentage. It's just sad to see the developers attacking the newbie dev's. At least he wants to help, so the least you can do is encourage and help him. If you don't want to answer his questions, then direct him to a place where he can get them answered, instead of bashing his ability (or lack there of).
Mr Ekted Posted February 2, 2004 Report Posted February 2, 2004 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.
»1587200 Posted February 3, 2004 Report Posted February 3, 2004 That's much more constructive than basicly saying, "Your skills suck, go somewhere else."
candygirl Posted February 3, 2004 Report Posted February 3, 2004 I have one. This is how it works 1st go in to the game/zone2nd click f113rd click tab and alt together There we go. If you did it right you will be in spec and in chat mod IM just messing with ya
ExplodyThingy Posted February 3, 2004 Report Posted February 3, 2004 Id like to refer those defenders of him to http://forums.minegoboom.com/viewtopic.php?t=2179 Nothing but help as given to him untill it became painfully obvious about how much he knew. Even then, as much as everyone disagreed with what he was doing or how he was going about it, he still got help.
Grelminar Posted February 3, 2004 Report Posted February 3, 2004 I never said anything about his skills. I just implied that he was asking too many questions. Mr. Ekted's analogy is good, but in this situation, there's no easy engineering course someone could point him to. Instead, there's the way everyone else learned the answers to the stuff he's asking: experimentation, packet sniffing, reverse engineering. That stuff is the easy part of writing something like what's he's attempting to write. If he can't do that on his own without help from 10 people on message boards, that's probably a sign that he's got a lot to learn first. I have no problem encouraging people doing productive things, and giving them help when necessary. But in this case it's pretty obvious to me that he's in over his head, and nothing will come out of this project.
Yupa Posted February 3, 2004 Report Posted February 3, 2004 end stupid argument> <continue any possible worthwhile discussion>
Earthshero Posted February 4, 2004 Report Posted February 4, 2004 Akai i have come from the future to warn you!
Mr Ekted Posted February 4, 2004 Report Posted February 4, 2004 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.
Trained Posted February 4, 2004 Report Posted February 4, 2004 if he finish's this I will use it I like the !@#$%^&*pects of what its gonna look like
mister manners Posted February 9, 2004 Report Posted February 9, 2004 Better yet, why don't you try doing some actual work on your own, rather than asking anyone who will listen to you about every little problem you come up against?thats why i quit trying to code, and started doing 3d modelling, no giesswork there
mister manners Posted February 9, 2004 Report Posted February 9, 2004 (edited) 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.and thats how certain programs that "speed up" your computer, but inm continuum you wil appear faster, but effectively, your movement will just look choppy on the other person't computer. like speeding up that GetTick() whatever Edited February 9, 2004 by mister manners
Mr Ekted Posted February 9, 2004 Report Posted February 9, 2004 and thats how certain programs that "speed up" your computer, but inm continuum you wil appear faster, but effectively, your movement will just look choppy on the other person't computer. like speeding up that GetTick() whateverYes, 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.
mister manners Posted February 9, 2004 Report Posted February 9, 2004 Also, I think Cont itself checks for "speedhack" although I don't know a thing about how it would do this.yea, in a way, so are you implying that it is possible to "speed up" total gameplay like in ut2k3. It is a Game speed setting in servers so if both the client and the server are running ______ program that speeds up the computer, the gameplay will go faster without the client getting booted. I bet it will work. Now to the testing platform! :syrus:
ExplodyThingy Posted February 9, 2004 Report Posted February 9, 2004 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.]Eh? I just noticed the note you stuck on there. So that I dont have to go diving into someone else's code, what exactly does Catid's code do incorrectly? Is it the infering data, transmitting data, or simply just the way it counts? And have you noticed this anywhere besides Merv?
Mr Ekted Posted February 9, 2004 Report Posted February 9, 2004 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.
mister manners Posted February 9, 2004 Report Posted February 9, 2004 speaking of merv, how does it shoot out of safe?or if you are too lazy, what sorce file should i d\l and look at
Mr Ekted Posted February 9, 2004 Report Posted February 9, 2004 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.
ExplodyThingy Posted February 10, 2004 Report Posted February 10, 2004 Mm, so whats gained from lopping off 2 bytes of data instead of just sticking in the string? And since you said its a problem with position packets of the bot itself, it should never be a problem for a standard bot, right? Someone point this thread out to Catid, as I not about to go delving through unfamiliar territory.
Mr Ekted Posted February 10, 2004 Report Posted February 10, 2004 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.
Recommended Posts