---
# System prepended metadata

title: Mounting System Design Notes

---

# Mounting System Design Notes
Pet tracking issue: https://gitlab.com/veloren/veloren/-/issues/800
## Cases to support
#### Mounting
- Attempt to mount while dead (should this be accounted for at a higher level that handles stopping all invalid control actions while dead)
    - handled by `handle_mount` at the moment (a complimentary check should also exist on the client to reduce unnecessary messages on the network)
- Distance limit (already exists?)
#### While Mounted
- Mountee dies
- Mounter dies
- Teleportation of mounter should teleport the mount instead
- Hierarchical mounting
- What parts of the controller to copy?
     - For example: when collecting items, starting trades, or interacting with things we need to make sure that it's the player that does that stuff
    - Mount controls should basically just be movement only (perhaps attacks too?)
    - Also make this work client side (might be automatic if in  `common`?)

#### Unmounting
- Placing umounted entity in a position where they don't trigger intense pushback with another entity
    - Could disable pushback between mounter and mountee and slowy move them to a designated unmounting offset (this would then theoretically push other entities out of the way)
    - Need to ensure unmounted entity is not placed inside terrain or within unmovable entities without compromising on avoiding overlap with the mountee unless absolutely necessary

## Misc
#### Note found in code (presumably from Sharp): 
```rust
/// FIXME: Make mounting more robust, avoid bidirectional links.
```
#### zesterer notes from discord pin:
* There are a lot of bugs, the way controllers are transposed from mounter to mountee is weird, we've got not real way to deal with state changes affecting the mounting relationship beyond manual checks, etc.
* I think, for example, mounting should become a `CharacterAction` so that it's difficult for weird things to happen when mounting ***(did zesterer mean `CharacterState`?)***
* We also need to figure out which parts of `Controller` need copying and which don't, and also make that work client-side
    * For example: when collecting items, starting trades, or interacting with things we need to make sure that it's the player that does that stuff
    * Mount controls should basically just be movement only (perhaps attacks too, but I'm unsure)
* There are also more things to resolve: when happens when the player gets teleported? Right now, teleportation doesn't work at all because the game just snaps the player back to the thing they're mounting
    * So somehow we need to make teleportation chase down the entity that the player is riding on (if any) and then perform the teleportation on that
* The question of hierarchical mounting also needs resolving at that point: is that someone we want to resolve?

#### Theoretical design from zesterer a while ago:
* We don't want to be hard-coding in lots of demounting logic on events like player or pet death and stuff like that
```rust
trait Relationship {
  type SystemData: specs::SystemData;
  type State;

  fn should_persist(data: &Self::SystemData, a: Entity, b: Entity) -> bool;
}
```
* `should_persist` would basically get called by a system for each relationship pair each tick
* It would check things like whether the entities are alive and stuff like that
* If it fails, ofc, the relationship gets destroyed

#### More random snippets?
