Entities appear to get stuck in walls/floors when sliding

[MrAwesomeLuigi]

Module

move

Feature

on_collision/slide

Version

2.2.2

Expected Behavior

The entity should move cleanly when applying a velocity and sliding

Actual Behavior

The entity clips into walls/floors when colliding with both blocks and entities. Any further velocity applied clips it further into the wall.

Possible Fix

From my testing it appears to be clipping into the floors/walls by -0.0000001 blocks, which appears to be messing with the collision checks, preventing it from sliding correctly. It appears to be directional in the negative direction for walls, although I haven't confirmed that 100%.

Steps to Reproduce

Runs Once

execute at @s run rotate @s ~ 0
scoreboard players set @s bs.vel.x 0
scoreboard players set @s bs.vel.y 0
scoreboard players set @s bs.vel.y 133000

Loop

execute at @s run function #bs.move:apply_local_vel {scale:0.00002,with:{on_collision:"#bs.move:on_collision/slide"}}

I have tested with different velocity scores and with canonical velocity instead of local, they all share this issue.

[aksiome]

Hey, thanks for reporting this! There’s already a system in place to prevent entities from clipping into blocks, but I may have been a bit too optimistic with the current values. In the function collision/resolvers/any, lines 21 to 26, there are multiple scoreboard additions handling this.

Could you try increasing the value and see if that resolves the issue? If not, I’ll have to dig deeper into this.

[MrAwesomeLuigi]

Increasing the value clips the entity further into the block. I managed to partially fix the issue by adding a specific check for 0 directly so it doesn't add the -0.0000001 offset. Seems to fix the clipping issue on my end, but I don't know what other effects that would have.

The slide collision appears to be working in the negative direction walls (NW), but it sticks in place on positive direction walls (SE). It also rarely appears to be bypassing collision checks at corners? It sometimes will move the full distance (2.66 blocks for me) when at a corner, and then gets stuck.

[aksiome]

And did you try with both (higher offset and 0 handling)? The set to 0 is a good thing, I kind of forgot to properly handle that when working on this. Right now this seems to be working for me:

# ------------------------------------------------------------------------------------------------------------
# Copyright (c) 2025 Gunivers
#
# This file is part of the Bookshelf project (https://github.com/mcbookshelf/Bookshelf).
#
# This source code is subject to the terms of the Mozilla Public License, v. 2.0.
# If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.
#
# Conditions:
# - You may use this file in compliance with the MPL v2.0
# - Any modifications must be documented and disclosed under the same license
#
# For more details, refer to the MPL v2.0.
# ------------------------------------------------------------------------------------------------------------

data merge storage bs:ctx {x:0d,y:0d,z:0d}
scoreboard players remove #move.ctime bs.data 10000
scoreboard players operation #move.ctime bs.data *= -1 bs.const
execute store result score $move.vel_remaining.x bs.data run scoreboard players operation #move.vx bs.data *= #move.ctime bs.data
execute store result score $move.vel_remaining.y bs.data run scoreboard players operation #move.vy bs.data *= #move.ctime bs.data
execute store result score $move.vel_remaining.z bs.data run scoreboard players operation #move.vz bs.data *= #move.ctime bs.data
execute if score #move.vx bs.data matches 1.. store result storage bs:ctx x double -.0000001 run scoreboard players add #move.vx bs.data 2
execute if score #move.vy bs.data matches 1.. store result storage bs:ctx y double -.0000001 run scoreboard players add #move.vy bs.data 2
execute if score #move.vz bs.data matches 1.. store result storage bs:ctx z double -.0000001 run scoreboard players add #move.vz bs.data 2
execute if score #move.vx bs.data matches ..-1 store result storage bs:ctx x double -.0000001 run scoreboard players remove #move.vx bs.data 2
execute if score #move.vy bs.data matches ..-1 store result storage bs:ctx y double -.0000001 run scoreboard players remove #move.vy bs.data 2
execute if score #move.vz bs.data matches ..-1 store result storage bs:ctx z double -.0000001 run scoreboard players remove #move.vz bs.data 2
execute at @s run function bs.move:collision/utils/tp_relative with storage bs:ctx
$function bs.move:collision/resolvers/$(resolver) with storage bs:data move

[aksiome]

Also quick note. I'm not sure why you are using this system for, but the #bs.move:apply_vel is more performant than the #bs.move:apply_local_vel so if you can, you should mostly use the canonical version. This is something that i wanted to add to the documentation but forgot. Basically if you are not manually updating the local velocity score at each step of the loop it's better to do this:

scoreboard players set @s bs.vel.x 100
scoreboard players set @s bs.vel.y 20
scoreboard players set @s bs.vel.z 50
function #bs.move:local_to_canonical

# Then run the loop

This way, scores don't get converted back and forth each time.

[MrAwesomeLuigi]

I applied higher offsets with the 0 check and it still seems to be getting stuck. I currently have the entity constantly moving to my position for better testing. Attached a video with both issues still happening.

Just found out that it reaches the 65536 command limit when trying to slide on the negative direction walls, so that may lead to something. It could also be something with how fast the entity is moving, but ideally I could get something working with that speed.

2025-02-07.08-57-02.mp4

[aksiome]

When testing with very low values, I noticed rounding errors in some places. Essentially, when I designed this system, I tried to save a few commands by using negative scaling with storage get. However, this causes values with many decimal places to round up instead of down, leading to some bugs. Hopefully, fixing this will also resolve the other issues. Also the fact that it reaches the command limit is normal since the resolution is not working, the system gets stuck in an infinite loop trying to fix it (but this should not happen in the first place)