NetworkProtocolSpec
From MountainfortWiki
for
NetworkProtocolSpec
Jump to:
navigation
,
search
<pre> C = Client S = Server protokoll generell : Each frame starts with a 0x00 byte, ends with a 0xFF byte, and contains UTF-8 data in between. json is used to encode data for ease of use. each message starts with {type:"messagetype"} if not defined otherwise each coordinates is noted in global tiles (mobiles have floating point tile positions) each chunk has 8x8x8 tiles * C -> S login ** erstes paket vom client an den server nach connection aufbau, server antwortet mit ** login confirm oder login denied ** danach werden vom server infos geschickt die der client braucht, je nach {"type":"login", "name":"heman", "pass":"battlecat", "nick":"heman"} * S -> C login denied {"type":"denied", reason:"bad user/pw"} -- "server full",... * S -> C login confirmed {"type":"confirmed",playerid:123,x:3.5,y:4.5,z:5.5} -- server assigns an id to the player and sends spawn-pos * S -> C create mobile {"type":"mobile_create", "id":123, nick:"player01", mesh:"zombie"} -- resync packet sent immediately afterwards for pos,rotation,size.. * S -> C remove mobile {"type":"mobile_remove", "id":123} * S -> C world size {"type":"world", "x": tiles_along_x, "y": tiles_along_y, "z": tiles_along_z} * C -> S movement -- player movement {"type": "move", "x":1.2, "y":2, "z":3.1, "vx":1, "vy":2, "vz":3, qw,qx,qy,qz} -- see notify movement * S -> C notify movement of mobiles -- used by server to send positions of others players, and to reposition own player (teleport, blocked movement...) {"type": "mobile_update", "id":123, "x":1.2, "y":2, "z":3.1, "vx":1, "vy":2, "vz":3, "sx":0.5, "sy":0.2, "sz":0.4, qw,qx,qy,qz} -- sx,sy,sz : optional size, not needed for normal resyncs. -- vx,vy,vz : current speed/velocity for smoother clientside-movement prediction -- qw,qx,qy,qz : orientation of mobile (quaternion) -- optional : different mesh, skin... (later) * S -> C chunk update {"type":"chunk_update", chunk_x,chunk_y,chunk_z, tiletype:".......", param:".....", lightlevel:"....."} -- chunk_x,chunk_y,chunk_z : in global CHUNK coordinates (first chunk=0, second chunk=1,...) (int) -- param : (rotation, liquid level...) (later) -- tiletype,param,lightlevel are all optional, so they can be individually updated if neccessary -- data is directly 1 byte per tile, no commas in between -- tiletype has assigned chars rather than id, e.g. grass='g' stone='s'... easier debugging, direct access via javascript getCharAtPos or so... -- buffer axis layout (tiletype,param,lightlevel): x0y0z0 x1y0z0 ... x0y1z0 ... x0y0z1 (note: y=up/sky, xz-ground plane) -- lightlevel encoding (62 different levels possible, 0=dark 62=light) "0" ... "9" : 0 - 9 "a" ... "z" : 10 - 35 "A" ... "Z" : 36 - 61 -- param buffer can contain other utf8 chars as well, like tiletype -- tiletype buffer example: tiletype="AAAABAAAACAAAADDDDDEEEFFFGGGGHHH" (other utf8 chars can be used as well : ,.- !"§$...) * S -> C tile update {"type":"tile_update", x,y,z, "tiletype":"x", "param":"ö", "lighting": "a"} -- updates a single tile -- uses the same encodings as the chunk_update message * C -> S chat {type:"chat",text:"bla..."} * S -> C chat {type:"chat",playerid:1234,text:"..."} -- playerid:0 is system message * C -> S target {type:"target",ox,ox,oz, tx,ty,tz, qw,qx,qy,qz, sideid} -- ox,ox,oz player/cam pos -- tx,ty,tz tile coords (int) of targetted tile -- qw,qx,qy,qz direction of player view (for weapons etc) -- sideid 0-5 : which side of the tile is targetted (0=front,1=back,2=left,3=right,4=top,5=bottom) -- front: lower z, back: higher z, left: lower x, right: higher x, top: higher y, bottom: lower y (note: to be confirmed with opengl standard coordinate system) * C,S -> S,C custom {type:"custom", "subtype":"blablub", ....} -- gameplay code can send custom messages in both directions -- gameplay code decides if, when and to whom to send those messages * S -> C gui -- gehen verschachtelte arrays ? ja, man kann complexe verschachtelungen schicken ich würde aber nur eine 1d liste von controls schicken -- {type:"gui_dialog",elements:[{...},{...},...],x,y,w,h,dialog_id:1234} -- element types : -- {type:"image",x,y,w,h,src:'http://blub.de/bla.png',mouseovertxt:'...'} -- {type:"button",x,y,w,h,src:'http://blub.de/bla.png',src_pressed="...",mouseovertxt:'...', returncode:444, closes_dialog:true} -- {type:"text",x,y,text="bla"} -- todo : font could be hard to realise in js -> later -- {type:"textinput",x,y,w,h} -- no visual border, must be placed with image behind it if neccessary. -- TODO : scrollable list ? (workshop items to build...) could be realized serverside by scroll buttons that close the dialog and send a new one * C -> S gui button -- {type:"gui_button",dialog_id:1234,returncode:444} </pre>
Return to
NetworkProtocolSpec
.
Views
Page
Discussion
View source
History
Personal tools
Log in
Navigation
Main page
Community portal
Current events
Recent changes
Random page
Help
Search
Toolbox
What links here
Related changes
Special pages