juanjpro wrote:The client has little authority over where it moves, since it only sends the keys that are being pressed and the collisions are handled entirely by the server.
What I meant is that if a player is too far away from something, the server will not tell the client about that thing.

Yea, that's what I thought of possibly doing when Adam was gonna write the server app. EDIT: The keystroke thing, not the distance vector thing; though that's good too. You mention that the client has little authority over where it moves. Does this mean that the client waits for confirmation from the server? Or do you let the client run as usual and rubberband when it de-syncs? Or do you do something else entirely?

juanjpro wrote:

MonocleBios wrote:Also, if you don't mind me asking purely out of interest, how(if you are that is) are you wrapping/unwrapping packets and doing confirmation checks?

I don't really understand what you're saying here.

Since you're using UDP, how are you structuring your packet sending/receiving? ie. Do you validate the order of the packets? What kind of headers do the packets have? etc.

MonocleBios wrote:Since you're using UDP, how are you structuring your packet sending/receiving? ie. Do you validate the order of the packets? What kind of headers do the packets have? etc.

The packets have a byte that tells the receiver what the packet is for. This is followed by an int that is used to validate the order of the packets. Old packets are ignored.

Clients send the keys and mouse buttons being pressed with two bytes, and their rotation (pitch and yaw, roll is ignored).
Servers send the positions and other important stuff about the nearest NPCs, players and "unpicked" Items, and the Items in the player's inventory. The Event states will be worked on later.

MonocleBios wrote:EDIT: The keystroke thing, not the distance vector thing; though that's good too. You mention that the client has little authority over where it moves. Does this mean that the client waits for confirmation from the server? Or do you let the client run as usual and rubberband when it de-syncs? Or do you do something else entirely?

It will move if it a server's packet is lost or takes to long to arrive, but if the positions de-sync then the client goes to where the server says.

How about if the host chooses if the cheats are allowed? Just a thought. Can also be helpful.

But then there would have to be a different opening and the menu would have to be edited which would distract the MOD progress

SubmerineRose36 wrote:But then there would have to be a different opening and the menu would have to be edited which would distract the MOD progress

I don't mean to be rude but, what?

D-9999 wrote:

SubmerineRose36 wrote:But then there would have to be a different opening and the menu would have to be edited which would distract the MOD progress

I don't mean to be rude but, what?

I think he means that effort will be diverted from development on the multiplayer engine to making a menu for cheats.

FYI, it'd take about an hour, max, thanks to all the GUI functions streamlining the process, and merely making a new option/variable "EnableCheats" or something like that.

Have you beta tested thus far, and are there any major bugs before the first release?

That Same Anon wrote:Have you beta tested thus far, and are there any major bugs before the first release?

I registered for a beta test along with a friend about half a year ago. I've never gotten an answer... (the mod developer was inactive I guess.

I created an account just to say that I am really hoping to see how this turns out and that i hope your endeavors come out true and well.

Wait for the surprise