For a hug, a paired pose or a wedding photograph, start with an emote resource that already supports two players. A marriage system is a separate requirement: persistent partners, name changes or shared accounts need their own documented server logic. Playing a couple animation does not create those records.
RPEmotes Reborn source and releases
Configure a verified emote resource
RPEmotes Reborn’s reviewed source declares version 2.1.4. Its setup guide uses the rpemotes-reborn folder and ensure rpemotes-reborn. The manifest requires OneSync and server artifact 6683 or newer; that minimum does not replace checking the project’s current release requirements. Configure your chosen release instead of copying unrelated dpEmotes instructions.
Control invitations and available animations
In config.lua, SharedEmotesEnabled controls shared emotes. F4 opens the menu by default and X cancels, though players can change mapped keys in FiveM settings. Set AdultEmotesDisabled to true if your community excludes flagged adult animations, and review custom additions separately. The normal shared-emote flow offers an invitation and a ten-second response window; it does not create relationship consent or database records.
Test two players before enabling it publicly
Test accepting, refusing, cancelling, moving away and disconnecting with two accounts. Check alignment with your actual peds, clothing and nearby objects. The reviewed server confirmation handler checks proximity but does not store and verify a pending invitation; have a developer validate that flow before relying on it to prevent forced interactions.
For persistent marriage features, require documented framework support, SQL migrations, character identifiers, permissions and rollback procedures from the chosen creator. Buy any additional animation pack from its creator and check redistribution terms. No fixed viewer count, unverified free marriage download or universal compatibility promise is needed to choose useful couple emotes.