packets and riders, almost. #TrainsInMotion #Traincraft (1.7 rewrite)
- There is now a packet to sync excess data between client and server. I wanted to avoid this because it creates a lot of lag in the port of TC, but it looks like I have no choice. The plus side is that its only needed for small amounts of data like the fluid tanks (that part isn't in the sync yet) and the rider entities. The booleans are probably necessary as well. Long run I don't expect it to be any more than a hundred bytes unless its a passenger car with 8+ seats.
In TC's port we had to sync everything, every tick (or was it every 2 ticks? I forget), which probably contributed significantly to the lag, on top of having significantly less data, the default for the new system is once every 10 ticks (twice a second), this should be significantly easier on bandwidth and hopefully won't create much lag. In the absolute worst case scenario I can even add in a degree of compression to the packets.
- The sync packet has the ability for its send frequency to be defined by the server's config (it will effect single player as well), the data isn't necessary for the game to work because it's all done on server side, but it's helpful to see how much fluid is in a tank, or for the player's position to be in smooth sync with the transport. The setting is from 1 to 20, 20 being once every second, and 1 being every tick.
- Riders are now defined via UUID which allows us to better manage persistent ID's so we don't accidentally lose track of an entity, this is also overall more reliable than using the entity ID because the value exists the same on server and client.
- Added a function to get an entity from any dimension based on it's UUID, on the server side this is actually very similar to the method used by vanilla in minecraft 1.8+. Client side a bit less.
This will allow me to re-define how I manage links and a number of other things, to make everything more reliable.
- Moved the mount functionality to it's own function so we can re-use it from the entity.
We are now on day 4 of me trying to get multi-passenger transports working, without question this has been a very difficult mess, and I did not expect in the slightest for it to be this much of a problem. But I think I'm close, and it has led me to create some things that will help significantly later, and fix some networking bugs I didn't notice before.
Hopefully I will have better news tomorrow.
In TC's port we had to sync everything, every tick (or was it every 2 ticks? I forget), which probably contributed significantly to the lag, on top of having significantly less data, the default for the new system is once every 10 ticks (twice a second), this should be significantly easier on bandwidth and hopefully won't create much lag. In the absolute worst case scenario I can even add in a degree of compression to the packets.
- The sync packet has the ability for its send frequency to be defined by the server's config (it will effect single player as well), the data isn't necessary for the game to work because it's all done on server side, but it's helpful to see how much fluid is in a tank, or for the player's position to be in smooth sync with the transport. The setting is from 1 to 20, 20 being once every second, and 1 being every tick.
- Riders are now defined via UUID which allows us to better manage persistent ID's so we don't accidentally lose track of an entity, this is also overall more reliable than using the entity ID because the value exists the same on server and client.
- Added a function to get an entity from any dimension based on it's UUID, on the server side this is actually very similar to the method used by vanilla in minecraft 1.8+. Client side a bit less.
This will allow me to re-define how I manage links and a number of other things, to make everything more reliable.
- Moved the mount functionality to it's own function so we can re-use it from the entity.
We are now on day 4 of me trying to get multi-passenger transports working, without question this has been a very difficult mess, and I did not expect in the slightest for it to be this much of a problem. But I think I'm close, and it has led me to create some things that will help significantly later, and fix some networking bugs I didn't notice before.
Hopefully I will have better news tomorrow.
Comments
Post a Comment