Is your feature request related to a problem? Please describe.
Currently, some advanced gameplay systems are limited by missing low-level control over object, player, and vehicle rotation.
For example:
SetPlayerAttachedObject has a limited number of attachment slots, forcing workarounds when more attached objects are needed.- Player rotation can only be controlled through
SetPlayerFacingAngle, which only affects horizontal rotation and does not allow full 3D orientation control.
- Vehicles also lack a native way to directly control full 3D rotation.
These limitations make it harder to implement advanced animation systems, custom interactions, effects, and movement mechanics.
Describe the solution you'd like
I would like to suggest the following API improvements:
- Increase the number of available indices in
SetPlayerAttachedObject, allowing more attached objects per player without requiring workarounds.
- Add a native function such as
SetPlayerRotation, enabling full 3D player rotation control instead of relying only on SetPlayerFacingAngle.
- Add a native function such as
SetVehicleRotation, allowing direct control over vehicle orientation in full 3D space.
These additions would significantly improve flexibility for developers building advanced custom gameplay systems.
Describe alternatives you've considered
At the moment, these limitations are usually worked around with custom systems, but they often introduce unnecessary complexity and performance costs.
For player rotation, servers that need custom movement systems (such as parkour, climbing, or advanced traversal mechanics) often rely on custom animation sets or animation replacements to simulate rotations that cannot be directly controlled. This significantly increases project size and maintenance complexity for something that could otherwise be handled natively.
For attached objects, developers often have to constantly remove and recreate attachments to free limited slots for temporary visuals or interactions. This becomes especially restrictive in projects with many persistent player attachments, such as DayZ-inspired systems where equipment, clothing, and carried items compete for the same limited slots.
Vehicle rotation is usually approximated through indirect movement manipulation or object-based synchronization tricks, which are less precise and harder to maintain than direct native control.
These workarounds only partially solve the problem and add avoidable complexity to systems that could otherwise be much cleaner.
Additional context
A practical example would be DayZ-style servers, where players may need multiple persistent visual attachments for gear, clothing, weapons, and temporary interaction states. The current attachment slot limit forces constant slot management and compromises feature design.
Another example would be parkour or advanced movement systems, where proper 3D player rotation would remove the need for large custom animation packages created solely to fake orientation changes that could otherwise be handled directly through scripting.
Is your feature request related to a problem? Please describe.
Currently, some advanced gameplay systems are limited by missing low-level control over object, player, and vehicle rotation.
For example:
SetPlayerAttachedObjecthas a limited number of attachment slots, forcing workarounds when more attached objects are needed.SetPlayerFacingAngle, which only affects horizontal rotation and does not allow full 3D orientation control.These limitations make it harder to implement advanced animation systems, custom interactions, effects, and movement mechanics.
Describe the solution you'd like
I would like to suggest the following API improvements:
SetPlayerAttachedObject, allowing more attached objects per player without requiring workarounds.SetPlayerRotation, enabling full 3D player rotation control instead of relying only onSetPlayerFacingAngle.SetVehicleRotation, allowing direct control over vehicle orientation in full 3D space.These additions would significantly improve flexibility for developers building advanced custom gameplay systems.
Describe alternatives you've considered
At the moment, these limitations are usually worked around with custom systems, but they often introduce unnecessary complexity and performance costs.
For player rotation, servers that need custom movement systems (such as parkour, climbing, or advanced traversal mechanics) often rely on custom animation sets or animation replacements to simulate rotations that cannot be directly controlled. This significantly increases project size and maintenance complexity for something that could otherwise be handled natively.
For attached objects, developers often have to constantly remove and recreate attachments to free limited slots for temporary visuals or interactions. This becomes especially restrictive in projects with many persistent player attachments, such as DayZ-inspired systems where equipment, clothing, and carried items compete for the same limited slots.
Vehicle rotation is usually approximated through indirect movement manipulation or object-based synchronization tricks, which are less precise and harder to maintain than direct native control.
These workarounds only partially solve the problem and add avoidable complexity to systems that could otherwise be much cleaner.
Additional context
A practical example would be DayZ-style servers, where players may need multiple persistent visual attachments for gear, clothing, weapons, and temporary interaction states. The current attachment slot limit forces constant slot management and compromises feature design.
Another example would be parkour or advanced movement systems, where proper 3D player rotation would remove the need for large custom animation packages created solely to fake orientation changes that could otherwise be handled directly through scripting.