Brainstorming: Physics and Packet Handling for Entities
#21
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.
Reply
Thanks given by:
#22
That might be because the velocity is sent in wrong units?
Reply
Thanks given by:
#23
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.
Reply
Thanks given by:
#24
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 serverBig Grin. Now moving on to the physics department...
Reply
Thanks given by:
#25
Great Smile
Reply
Thanks given by:
#26
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?
Reply
Thanks given by:
#27
Ooh sounds interesting. I'd say yesm as long as it doesn't bean re-reading the value every time gravity is calculated.
Reply
Thanks given by:
#28
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 Smile
Reply
Thanks given by:
#29
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 Smile It will be great because the handlePhysics function can use it to access blocks directly since right now it is using GetBlock on each tickBig Grin
Reply
Thanks given by:
#30
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.
Reply
Thanks given by:




Users browsing this thread: 9 Guest(s)