Speed calculation logic
porl opened this issue ยท 3 comments
Trying to get things working more consistently for the speeds of the speed clamp rail and the high speed rail.
As you mentioned in the other PR, my speed clamp rail uses cart.setMotion() as opposed to the usage of cart.move() by the high speed rail.
Apart from the logic in the parameters passed to move() for acceleration (as opposed to the clamp's immediate setting to a value) are there any other reasons to use move() instead of setMotion()?
The reason I ask is because in trying to test why some values appeared to be ignored I noticed that even doing a move(Vec3d.ZERO) and disabling all other move code in the powered part of the CustomPoweredRailBlock class it seemed that the standard powered rail logic overruled it, whereas using setMotion(Vec3d.ZERO) works as expected.
Are there some corner cases that require the use of move()? If not, is there any reason why I can't refactor them both to use setMotion()?
Cheers!
Looking a little further into it and noticed some interesting things.
The Entity.move() code performs a fair amount of logic and ultimately either performs some form of setMotion() or essentially a teleport. The setMotion() just directly updates the private motion field.
Using each one has its own drawbacks - using setMotion() does not seem to allow for higher speeds, as there is a fair bit of checking of speed caps etc. in other parts of the AbstractMinecartEntity class and so on (at least that is my thought as to why the speed seems to be capped). Using move() however has the opposite effect where you can't reliably run lower speeds as some of the above mentioned logic also assumes normal powered rails etc.
The only seemingly reliable solution is to set both to the same values (perform a setMotion() and then a move()). This feels hacky but I think what is happening is the motion field is being set and then the move logic will work better.
After some testing I'll perform a PR with the changes for you to check.
