Core/Movement: fixed an issue in the spline synch packet that was causing cyclic splines to get asynch

This commit is contained in:
Ovahlord
2019-10-05 07:47:29 +02:00
parent e135d35551
commit b40b738975
2 changed files with 4 additions and 3 deletions

View File

@@ -290,8 +290,8 @@ MoveSpline::UpdateResult MoveSpline::_updateState(int32& ms_time_diff)
args.flags = splineflags;
args.path_Idx_offset = point_Idx_offset;
// MoveSplineFlag::Parabolic | MoveSplineFlag::Animation not supported currently
//args.parabolic_amplitude = ?;
//args.time_perc = ?;
//args.parabolic_amplitude = ?;
//args.time_perc = ?;
args.splineId = m_Id;
args.initialOrientation = initialOrientation;
args.velocity = 1.0f; // Calculated below
@@ -301,6 +301,7 @@ MoveSpline::UpdateResult MoveSpline::_updateState(int32& ms_time_diff)
{
// New cycle should preserve previous cycle's duration for some weird reason, even though
// the path is really different now. Blizzard is weird. Or this was just a simple oversight.
// Since our splines precalculate length with velocity in mind, if we want to find the desired
// velocity, we have to make a fake spline, calculate its duration and then compare it to the
// desired duration, thus finding out how much the velocity has to be increased for them to match.

View File

@@ -245,6 +245,6 @@ namespace Movement
void PacketBuilder::WriteSplineSync(MoveSpline const& moveSpline, ByteBuffer& data)
{
data << float(moveSpline.timePassed() / moveSpline.Duration());
data << (float)moveSpline.timePassed() / moveSpline.Duration();
}
}