issue with players updating
Blitz3D Forums/Blitz3D Programming/issue with players updating
| ||
| I have an issue with my player update code the way it works is it sends through the network a 1 for forward 2 for back 3 for left 4 for right but if someone hits left and forward or right and forward it doesnt send those...and my net characters get all discombobulated..positions off etc any ideas? chris here is my player update code: Function UpdatePlayer( p.Player ) If KeyHit(56) ;fire? ; CreateBullet( p ) EndIf If KeyDown(203) ;left/right SendNBMsg(2,"3",0,mainstream) TurnEntity p\entity,0,6,0 ;turn player left/right ElseIf KeyDown(205) SendNBMsg(2,"4",0,mainstream) TurnEntity p\entity,0,-6,0 EndIf If KeyDown(30) ;forward If p\anim_speed<=0 p\anim_speed=1.75 anim_walk(p) EndIf SendNBMsg(2,"1",0,mainstream) MoveEntity p\entity,0,0,1 ElseIf KeyDown(44) ;back If p\anim_speed>=0 p\anim_speed=-1.75 anim_walk(p) EndIf SendNBMsg(2,"2",0,mainstream) MoveEntity p\entity,0,0,-1 ElseIf p\anim_speed ;stop animating p\anim_speed=0 anim_idle(p) EndIf Goto skip ex#=EntityX(p\entity):ez#=EntityZ(p\entity) PositionEntity p\entity,ex,TerrainY( land,ex,0,ez )+1.5,ez Return .skip ty#=EntityY(p\entity) y_vel#=(ty-p\player_y) p\player_y=ty If KeyHit(57) ;jump? y_vel=5 ;2.4 Else y_vel=y_vel-.5 ;2 EndIf TranslateEntity p\entity,0,y_vel,0 p\px=EntityX(p\entity) p\py=EntityY(p\entity) p\pz=EntityZ(p\entity) p\rx=EntityPitch(p\entity) p\ry=EntityYaw(p\entity) p\rz=EntityRoll(p\entity) my_status$="A" End Function |
| ||
| I mean hitting the two keys at the same time - left and forward or right and forward or left and back and right and back |
| ||
| Not big on networking stuff but you should gather all the inputs before you send them. Set a variable Move$ = "" each frame, if left key pressed add "3" to move$ and if up key pressed add "1". So, move$ = "31". At the end of the loop if move$ <> "" then send this information. You should then be able to easily get the 3 and the 1 from this string and move, turn accordingly. |
| ||
| Why not just send the position/rotation of the player after updating the player locally. The other clients don't need to know what keys were pressed, only where the other player is. I assume you have another function that has to parse the messages and extract what key was pressed and then move the remote player. Much easier to just get a message with the remote players current position and rotation. |
| ||
| I don't think you should send keypresses at all. Unless you fire or something like that. Because some people tend to try to 'break' your server by pressing multiple buttons REALLLLLY fast. Just send the x,y (or x,y,z depending on what kind of game it is) coords periodicly every .5 - 1.5 seconds and use delta morphing to smooth out the players' positions when it updates in the multiplayer game. If this sounds too complicated then kill the delta morphing and just send the coords and work it out :D [edit] OOOPPPPSSS!!!!! Sorrrrryyyy Ricky Smith. I didn't read the other posts. I have no intention of copying somebody else's post :( |
| ||
| explain delta morphing please ;) |
| ||
| Detla is the difirents from current position value. X1=100 ; old position X2=200 ; Destination DeltaX = X2-X1 ; Difirent and if you devide the DeltaX into smal parts you till get nice movements :) so instead of sending an update for every pixel move. just send position over time. The important in delta move is time and length. |
| ||
| how do you do deltas over time...i understand to get the different you do x1-x, y1-y, z1-z then thatll give you the difference in each position.. how do you do the updates from that point however? chris |
| ||
| well i an rpg like wow delta in time is not used at all. instead all npc and player have built in moving system. in fps game like counter strike delta moves is better to use. player X1 moves to 10,23 player x2 moves to 23,3133 player x3 moves to 302,132 player x4 smiles :) |
| ||
| I've tried doing like that, where you just send the key presses and the server does the rest. That's the way I thought GarrysMod did it because if there's any lag at all, you know it because you can't move. I've also tried this (this is the first thing I tried) where you just send the coordinates and the server updates all the players, and sends the coordinates back. The problem is, both are slow, or I'm just doing it wrong. But this way is faster but trying to add things like, "Pickup-able", items is freakin hard. And btw, the "delta" thing only makes it worse. Sometimes the player would move past where he actually went, on another screen, because of the delta, it's freaky :O. I understand that it's supposed to smooth the movement, but it doesn't position them in all the places they've been though. Also, sometimes you get surges of info in the server and the client which creates lag (pretty much just visual lag, not connection lag), like hiccups. |
| ||
| There's a lot of things that you can do wrong with multiplayer. General idea is to keep packet sizes small. But this sometimes leads to huge amount of packets, which is also bad. If half of the cumulated data you send over is timestamps, you're doing it wrong. Optimising network performance means balancing between packet size and frequency. Sometimes the optimation has to be done on the fly, per client. So if one client has a bit higher ping, you should send less packets per second. One important way to reduce jerkiness is permanent lag in client side. If you show stuff to the user like 60 milliseconds late, then the client basically has 60 ms window to receive correct responses from server. Usual lan games have less than 10ms lag (around 50 in wan), so that's quite enough. So basically you wont be forecasting player positions, but running the whole game logic in advance. This has it's own problems, but I think it's better than not using it. Most of the time you want the client end to handle game logic by itself and use the data from server to adjust. Pickup-able items have to be handled in the servers terms, because you can't have two clients thinking they picked up something and have server take it away from the other. As you are using B3D, you aren't using multi-threading. MT is important for at least the server. The packets need to be handled as they come, not when the server is executing the next tick. In B3D, I would create another program, call it a "node", that would listen for packets from clients. When a packet arrives, forward it to other clients and send a receipt to the sender. It would also sort all the arrived packets and send them to the actual server program (via UDP also) in bigger chuncks. The server would run the actual game in ticks (say 50-100 loops per second). Server sends status packets to clients either directly or through the node if needed. So if you understood this correctly, you see that if server is one of the players and he is using vertical sync (Flip true), the server is sitting useless for huge amounts of time when it should be handling packets like crazy. |
| ||
| hmm... Two programs being the server :D sounds good. One of the problems I picture in my mind with the way I've been doing it the whole time is, while the server is busy looping through all the players, it cant receive any updates from the clients, which means the clients have to wait for an update from the server. Once the server is done looping through all the necessary junk, it spits it out to all the clients, while looping even more trying to update again. But if you have one server receiving the coords, and the other server program updating and sending, that'd be harder, better, faster, stronger :D |
   |