New pathfinding #TrainsInMotion #Traincraft (1.7.10 rewrite)
Alright so I have started the baselines for the new motion and pathfinding system.
Long run it should be more accurate, simpler, and have less overhead than vanilla methods.
It also fixes the wonky height offsets where they phase into the ground.
If you care for theoretical technical notes, here's some I cooked up while making dinner.
Calculate the current velocity, then convert the velocity into blocks per second, then for each block per second rounded up, we check if the block is the correct tile entity, if it is then we check the metadata of the block to define the direction for the next check assuming there is one.
Then we move on an angle from the current position to the last position in the loop, assuming the loop succeeded.
If the loop has failed then we set the motion velocity to zero, because the only way to fail would be to not detect a track at all.
From there, derailing around corners (and thus the roll) can be calculated by yaw change compared to speed.
And the usual list of stuff changed:
- Fixed a glitch with the bogie render position.
- Removed some unnecessary values in the new bogie.
- Fixed improper position of the CMDBogie model.
- Renamed the bogie offsets to represent that they will only be for rendering.
- Added a new offset value that will be used for actual position and motion calculations.
- Added a testing function as a baseline for the new pathfinding method.
Long run it should be more accurate, simpler, and have less overhead than vanilla methods.
It also fixes the wonky height offsets where they phase into the ground.
If you care for theoretical technical notes, here's some I cooked up while making dinner.
Calculate the current velocity, then convert the velocity into blocks per second, then for each block per second rounded up, we check if the block is the correct tile entity, if it is then we check the metadata of the block to define the direction for the next check assuming there is one.
Then we move on an angle from the current position to the last position in the loop, assuming the loop succeeded.
If the loop has failed then we set the motion velocity to zero, because the only way to fail would be to not detect a track at all.
From there, derailing around corners (and thus the roll) can be calculated by yaw change compared to speed.
And the usual list of stuff changed:
- Fixed a glitch with the bogie render position.
- Removed some unnecessary values in the new bogie.
- Fixed improper position of the CMDBogie model.
- Renamed the bogie offsets to represent that they will only be for rendering.
- Added a new offset value that will be used for actual position and motion calculations.
- Added a testing function as a baseline for the new pathfinding method.
Comments
Post a Comment