Motion dampened on every axis except Y after top-side block collision

[woobdude]

Hi, I'm working on writing a basic mod for Vintage Story in F# as a little experiment to see how viable it is to write a mod for a C# game in a functional language.  I don't think any of my issues are related to it being an F# mod, given that compilation all seems to go fine, but I'm running into an issue after slightly modifying the Trampoline example from the code mod tutorials.  Inside my block class, I have this override:

    override _.OnEntityCollide (
        world: IWorldAccessor,
        entity: Entities.Entity,
        pos: Vintagestory.API.MathTools.BlockPos,
        facing: Vintagestory.API.MathTools.BlockFacing,
        collideSpeed: Vintagestory.API.MathTools.Vec3d, isImpact: bool
    ): unit =
            match entity with
            | :? EntityPlayer as player ->
                player.Pos.Motion <- player.Pos.GetViewVector().Mul(0.3f).ToVec3d()
                ()

Now, when the event gets triggered from landing on top of a block, the X and Z motion persist for about a frame before getting snubbed to 0.0 (or something close to it).  However, if one walks into the side of the block and looks upward of the horizon, they'll be pushed upwards until they can clear the edge of the block, and the X and Z motion persist, flinging the player along their look vector as intended.  This kind of leads me to believe it's caused by an effect that only occurs when the player has been on the ground, since the player will not have been touching the ground for a bit of time before they are high enough to be flung over the block they've run up against.

For anybody unfamiliar with F#, `<-` is how you write to class members, and `unit` is equivalent to C#'s `void`.  The last line of a function can just be an expression that gets returned, and `()` is the only valid value of `unit`.  So, to translate, this is a function which checks whether the collided entity is an EntityPlayer, sets their Motion vector to a scaled copy of their ViewVector, and returns nothing at the end.  `_` could be replaced by `this` or any other variable name and would allow access to an instance of the Block class I've defined.

So, how would I go about hunting down the part of Vintage Story's code which causes my block to fail when the player lands on the top side of the block?  Has anybody else dealt with a similar issue in creating a related block?  I have Harmony verified as working with my mod, so I can inject/patch as needed to change this behavior; I just need to know what class(es) may be causing this.

So far I have tried:

• Disabling PModuleOnGround with a patch to its Applicable method, and
• Patching EntityBehaviorPlayerPhysics::HandleRemotePhysics to disable a line which sets the player's motion vector to the zero vector when its length exceeds 20.

I tried to debug this by setting a breakpoint at various points where the motion vector gets changed, but when the debugger suspends the game, I'm unable to view my mouse cursor inside JetBrains Rider, and thus can't navigate to set watches on the X and Z values of the motion vector.  If anybody has any advice on getting that working that'd be appreciated as well.

EDIT 1:
I just had an idea as to how I could do this without patching.  Is there any way I could add a new physics module onto the player and ensure it runs last out of all of the player's physics modules?  This way, I imagine I could ignore changes set by previous physics modules and properly set the player's velocity.

Edited January 1 by woobdude
Small idea as to how I might resolve this