Sending op codes to the server more efficiently
When the vector for the camera in changed, a "move" operation is sent to the server. I suspect this is because any change in the vector results in a operation being sent to the server. This results in many spurious move updates on a stationary entity. There should be some additional logic that can limit excessive updates, as updates lend to lag ( ember appears very choppy when I "look around" ).
For example, making a 90 degree rotation on the X axis quickly, results in about 4 opcodes being sent, but if this is done slightly more slowly, it results in 4-5 times the number of updates. Similarly, if you were to rotate, 90 degrees, and then back 45 degrees ( a net of 45 degrees ), the opcodes are generated as if these rotations are separate. We should have different type of movement events, and they should update differently. So a start/stop event would be critical, and should be sent right away, but if you were running and altered your course by 5 degrees, this should be updated at the next interval. I don't know the atlas block that describes a move operation, but perhaps if ember kept the last update it sent, and if the vector changed by a certain amount, or the interval had lapsed ( whichever happened first ), a new update could be sent.
[23:57:35] VERBOSE Sending move op to server.
[23:57:35] VERBOSE Sending move op to server.
[23:57:35] VERBOSE Sending move op to server.
[23:57:36] VERBOSE Sending move op to server.
[23:57:36] VERBOSE Sending move op to server.
[23:57:36] VERBOSE Sending move op to server.
[23:57:36] VERBOSE Sending move op to server.
[23:57:39] VERBOSE Sending move op to server.
[23:57:40] VERBOSE Sending move op to server.
[23:57:40] VERBOSE Sending move op to server.
[23:57:40] VERBOSE Sending move op to server.
[23:57:40] VERBOSE Sending move op to server.
[23:57:42] VERBOSE Sending move op to server.
[23:57:42] VERBOSE Sending move op to server.
[23:57:42] VERBOSE Sending move op to server.
[23:57:43] VERBOSE Sending move op to server.
[23:57:43] VERBOSE Sending move op to server.
Blueprint information
- Status:
- Complete
- Approver:
- Erik Ogenvik
- Priority:
- Not
- Drafter:
- Sean Ryan
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Erik Ogenvik
- Completed by
- Erik Ogenvik
Related branches
Related bugs
Sprints
Whiteboard
This is actually how Ember behaves currently. :)
When in movement mode, if the orientation of the camera changes, the system only updates the orientation of the avatar with a certain interval, which is set in ember.conf:
This is to prevent the client from swamping the server. The default is 250 milliseconds. However, all changes to the movement vector (stop, start, changing between running and walking speed) are sent instantly. This is because they are crucial for making sure that the server and client are in sync. So, for example, if you begin to walk and walk in an arc, the client will only change the orientation of the avatar every 250ms. Since it's set so low you won't notice the jerkyness much, but if you set it higher (you can alter it in game with "/set_value general avatarrotationu
Now, Al has talked about adding support in cyphesis for perpendicular movements, but it's not something that exists yet (i.e. the only movement update is a move up which always contains a movement vector and an orientation).
The choppyness you describe is most probable caused by this issue: https:/
