Hello everyone, long time no see in this thread.
As i mentioned last year, the Dual Ride Pair system was one of the custom features i had started developing and later parked. At that time, i was working on several different modifications at once, and many of them were left unfinished.
Recently, i decided to change that approach completely: stop starting multiple new systems and return to finish each existing project properly, one by one.
The Dual Ride Pair system is now the first of those parked projects to reach a fully working state.
After seven intense days of development, fianlly we can see fully synchronization workingk, and repeated multi-client tests all green light, the feature is now 100% functional and has entered its final packing and protection phase.
Players can invite another player to ride with them, request a ride from a mounted player, accept or refuse invitations, cancel pending requests, and leave the pair safely at any time. The system supports multiple custom mounts, with each mount using its correct passenger position, animation, visual attachment, and weapon-display behavior. atm ive added 16x mounts, there are so many lol, and each one of these requires a different linkage from server to client / client to server, such as comunication handelrs , positions and specific geodata safe guards.
The movement is fully synchronized between host and passenger. The passenger follows the host correctly, remains attached to the mount, uses the proper riding pose, and shares the expected camera behavior without interfering with the hosts movement or normal mount controls.
The system also includes complete packet delivery and synchronization for nearby players. ( whos into observer mode) Other clients can correctly see the host and passenger riding together, including after entering view range, changing position, teleporting within the same scene, or rebuilding visual objects.
A custom sandbox and server-authoritative pair state were created specifically for this system. The client does not control the final pair state by itself the server validates invitations, distance, scene, mount compatibility, current status, and all important lifecycle operations.
Several safeguards were also added, including:
• Geodata, distance, and scene validation
• Cross-scene and instance-entry protection
• Teleport and traffic-route safeguards
• Stall and guild-territory protections
• Death, disconnect, kick, unmount, and cleanup handling
• Passenger movement, skill, action, sit, and auto-walk restrictions
• Automatic visual repair when models or presentation objects are recreated
• Correct observer synchronization for nearby players
• Protection against invalid or duplicated pair states
This was not simply to place a second character on top of a mount. The objective was to make the system behave like a complete native feature, including invitations, synchronization, restrictions, cleanup, recovery, and protection against situations that could separate the players or leave broken visual states. ( leading to disgraces )
The system was tested with multiple clients simultaneously and across different accounts, mounts, actions, teleports, scene conditions, stalls, guild territory interactions, disconnects, and repeated pair cycles. deaths, revives and crazy possible state.
Everything working smoothly. ; p
I think the next fully-fledged mod will involve the full pack of new game classes. Yes, the goal is not to implement them as they currently appear in the community—bugged, ugly-looking, and far from feeling native. There are three new classes: Tamer (male), Little Fox, and Netheaven. These will require a complete reconstruction, including default animations and a proper lifecycle."