Rider Token does not move with mount

[KJTailor]

Rideable version 4.0.20

When I mount a token on a mount, the rider has their elevation changed accordingly, but afterwards does not move, neither to be visualy mounted on the mount, nor when the mount is being moved.

If the rider is being moved, the mound moves instead, but the rider token itself remains stationary.

Sorry, the console is not giving me much that seems related, but here are some screenshots of what pops up when I press m to mount a rider on a mount

[Saibot393]

Which system and which system version are you using?

[KJTailor]

Apologies, I should have mentioned that:

Draw Steel 0.8.1
Foundry 13.148? (whatever the most recent in is)

[Saibot393]

One other question, how did you test the mounting, i.e. was the account you used a GM or a Player account, in case of a Player Account, was a GM account also loggen in at the same time?

[KJTailor]

I have not tested it on a player account yet. I have only tested it on the GM account.

Give me an hour or two and I will check if it's maybe a module interference

[KJTailor]

Ok by now I can confirm, it is a different module: Terrain Mapper

With Terrain mapper deactivated, Ridable functions as intended.

[Saibot393]

Curious, i have a few ideas on what might be the Problem there, i will do a few tests

[Saibot393]

I have tested a bit and it seems like Terrain Mapper is somehow disabling a new api function that foundry introduced with v13(?) token.move() which rideable relies on. Since this function stops behaving as expected even without Rideable i would for now assume that this is a Terrain Mapper bug and not (directly) a Rideable Bug, i will create an issue on Terrain Mapper for that

[Saibot393]

I have released a temporary compatibility fix with v4.1.4

[Mega-Lonyx]

The mounting conflict between rideable and terrain mapper seems to still be occuring with Familiar Mounting.

When a familiar is offset mounted, it freezes position while the ridden token moves (with terrain mapper enabled).

[Saibot393]

I somehow used the wring module id in my innitial fix (or the id changed recently?). I have corrected that with v4.1.6, though that should not affect fimilars uniquely.