+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Brainstorming: Physics and Packet Handling for Entities (/thread-824.html)
RE: Brainstorming: Physics and Packet Handling for Entities - keyboard - 04-07-2013
I finished the head yaw a couple of days ago. Now, I am working on getting the physics corrected at least for mobs. I am seeing that the MCServer and the client are out of sync when the mob is moving, so the mob jumps almost a full block forward when the server sends the teleport packet to force a sync.
RE: Brainstorming: Physics and Packet Handling for Entities - xoft - 04-07-2013
That might be because the velocity is sent in wrong units?
RE: Brainstorming: Physics and Packet Handling for Entities - keyboard - 04-07-2013
Could be, but I am not seeing jumps when the Relative Move is sent. Mmmm, I'm going to disable the velocity to see how the relative move is doing.
RE: Brainstorming: Physics and Packet Handling for Entities - keyboard - 04-07-2013
interesting, I am seeing the same jump after a while with just the relative move and no velocity...
I found the issue: it was a combination of bad flooring of integers in both the relative move and the teleport packet and the order that the packets were sent to the client. I fixed both, and now the little piggy mob in the client is walking in synch with the server
. Now moving on to the physics department...
RE: Brainstorming: Physics and Packet Handling for Entities - bearbin - 04-07-2013
Great
RE: Brainstorming: Physics and Packet Handling for Entities - keyboard - 04-10-2013
So, I am working on the physics function, and I am thinking of having the gravity constant as a value in the cWorld class that can be tweaked in the world.ini. This way we can have worlds with different gravity values. What do you guys think?
RE: Brainstorming: Physics and Packet Handling for Entities - bearbin - 04-10-2013
Ooh sounds interesting. I'd say yesm as long as it doesn't bean re-reading the value every time gravity is calculated.
RE: Brainstorming: Physics and Packet Handling for Entities - xoft - 04-10-2013
I'm afraid it won't work well with the client, because the client seems to do gravity calculation on its own. But we won't know unless we test that, so I'd say make it a variable and if you change its value and everything behaves okay, then make it settable in the ini.
A different question now. How much are you working with the cEntity::Tick() function? I'm thinking about rewriting entities to tick within their respective chunks, which would mean this function will get another parameter, cChunk *, which it could use to query blocks directly. Will that collide with your code much? I don't want to start a svn conflict war
RE: Brainstorming: Physics and Packet Handling for Entities - keyboard - 04-11-2013
Yeah, i think you might be right. The client seems to have hardcoded the gravity calculations for the player, but it will accept any position/speed regarding entities. I am going to test and see what is the behavior in the client.
Actually, I haven't touch the entity tick function yet directly, so feel free to go ahead and add the cChunk parameter
It will be great because the handlePhysics function can use it to access blocks directly since right now it is using GetBlock on each tick
RE: Brainstorming: Physics and Packet Handling for Entities - xoft - 04-11-2013
Adding the parameter will actually take some time, maybe a week, so if that timeframe is still okay with you, I'll go ahead.
It's not only about adding the parameter, it also involves moving the tick call to within the chunks, and hence the individual chunks will own the entities, unlike now, when they are owned by the cWorld. I'm not even sure if cWorld will have a list of all entities. So the change is quite profound. Still, it would be wise to do it before you touch any actual physics code too much - as you said, access to the cChunk will be quite beneficial there.