AI that actually speaks Tunnel/Proxy

vRP AI Script Generator

Most AI tools treat vRP like “ESX with different names.” It is not. SwisserAI generates vRP-native code: Tunnel and Proxy RPC, vRP 2 and Dunko idioms, real inventory and group APIs — not hallucinated exports.

Start Free (250 credits)See Pricing

vRP is its own thing — code it that way

vRP predates most modern FiveM frameworks and has an architecture to match: a Tunnel/Proxy RPC layer instead of events and exports, persistent integer user ids instead of licenses, group-based permissions instead of a single “job” field. If you have only ever touched ESX or QBCore, vRP looks familiar — and then it bites you the moment you try to use either's idioms.

Generic AI models have seen far more QBCore and ESX code than vRP. So they happily emit ESX.GetPlayerFromId in a vRP resource, register client events where Tunnel is the right tool, and call exports.vrp:something() — an export that does not exist. The code looks plausible. It does not run.

SwisserAI is grounded on the actual vRP 2, vRP 3, and Dunko vRP source. Generations use Tunnel and Proxy where vRP uses Tunnel and Proxy. They respect wallet vs. bank money semantics. They bind interfaces the way vRP resources actually bind them.

vRP coverage

Tunnel & Proxy RPC

Tunnel.getInterface and Proxy.getInterface wired correctly. vRP and vRPclient calls on the right side, with the right arg order.

vRP 2 + Dunko vRP

Output matches the idioms of vRP 2 (the canonical vRP-framework/vRP) and Dunko vRP — the two trees most live servers run.

Group & permission APIs

vRP.hasPermission, vRP.addUserGroup, vRP.getUserGroups — not invented wrappers. Works with vRP groups.cfg out of the box.

Real inventory surface

vRP.giveInventoryItem, vRP.tryGetInventoryItem, vRP.getInventoryItemAmount, vRP.defInventoryItem — the functions your scripts actually call.

Money that matches vRP

vRP.giveMoney, vRP.tryPayment, vRP.getMoney, vRP.giveBankMoney — respecting wallet vs. bank account semantics.

User IDs and identity

vRP.getUserId, vRP.getUserSource, vRP.getUserIdentity — the vRP id model, not a QBCore citizenid mental mix-up.

vRP-idiomatic output

What a SwisserAI vRP generation actually looks like.

Tunnel/Proxy setup

The boilerplate every vRP resource needs, done right the first time.

-- server.lua
Tunnel = module("vrp", "lib/Tunnel")
Proxy = module("vrp", "lib/Proxy")

vRP = Proxy.getInterface("vRP")
vRPclient = Tunnel.getInterface("vRP", "swisser_bakery")

swisser_bakery = {}
Tunnel.bindInterface("swisser_bakery", swisser_bakery)

Group-gated server call

Only users in the baker group can call this function.

function swisser_bakery.sellBread(amount)
    local user_id = vRP.getUserId({source})
    if not user_id then return false end

    if not vRP.hasGroup({user_id, "baker"}) then
        vRPclient.notify(source, {"You are not a baker."})
        return false
    end

    local stock = vRP.tryGetInventoryItem({user_id, "bread", amount, true})
    if not stock then
        vRPclient.notify(source, {"Not enough bread."})
        return false
    end

    vRP.giveBankMoney({user_id, amount * 15})
    vRPclient.notify(source, {"Sold " .. amount .. " bread."})
    return true
end

Defining a usable item

vRP.defInventoryItem with a choice callback — the vRP way, no RegisterUsableItem.

vRP.defInventoryItem({
    "bread",
    "Bread",
    "Freshly baked.",
    {
        ["Eat"] = {
            function(player, choice)
                local user_id = vRP.getUserId({player})
                if vRP.tryGetInventoryItem({user_id, "bread", 1, true}) then
                    vRP.varyHunger({user_id, -25})
                    vRPclient.notify(player, {"You ate bread."})
                end
            end,
            "Restore hunger.",
        },
    },
    0.2
})

vRP mistakes we prevent

Classic generic-AI vRP output patterns we do not emit.

Confusing vRP with ESX or QBCore

Generic AIs love to stuff ESX.GetPlayerFromId into a vRP script. vRP has no xPlayer — it has user ids, Tunnel interfaces, and group membership. SwisserAI generates vRP, not ESX with a rename.

Wrong side for the call

Tunnel separates server-exposed functions (vRP) from client-exposed ones (vRPclient). Calling vRPclient.getPed() on the server, or vRP.getUserId() on the client, is a classic generic-AI bug. We get the side right.

Hallucinating exports instead of Tunnel

vRP resources almost never use exports — they use Tunnel.bindInterface + Proxy.getInterface. Models that have only seen QBCore emit exports.vrp:someFunction(), which does not exist.

vRP 1 syntax in a vRP 2 project

vRP 1 and vRP 2 are different codebases with overlapping but not identical APIs. SwisserAI knows which one you are targeting and matches.

Running Dunko vRP, vRPex, or a custom fork?

Most vRP servers do not run stock vRP. SwisserAI is indexed on vRP 2, vRP 3, Dunko vRP, and widely-used community forks — so generations match what your server actually exposes, not a clean-room vRP manual.

If your fork renames a handful of APIs, drop a note in the prompt or paste a sample from your codebase. The output will follow your spec.

Try vRP generation

Frequently Asked Questions

vRP is one of the oldest FiveM roleplay frameworks, originally by ImagicTheCat and now community-maintained at github.com/vRP-framework/vRP. It is built around a Tunnel/Proxy RPC architecture instead of the event-based model used by ESX and QBCore. vRP 2 is the current canonical version; vRP 3 is in development. Popular forks include Dunko vRP and vRPex.

The core difference is how server and client talk. ESX and QBCore rely on RegisterNetEvent, callbacks, and exports. vRP exposes whole interfaces — Tunnel.bindInterface("vRP", vRP) on the server — that the other side calls with Proxy.getInterface("vRP") or Tunnel.getInterface(). User identity is a persistent integer user id, not a Rockstar license. Groups and permissions are a first-class concept (vRP.hasPermission("police.handcuff")) rather than job fields on a player object.

SwisserAI is grounded on the current vRP 2 (vRP-framework/vRP), vRP 3 development branch, Dunko vRP, and several widely-used forks including imperfect-fivem/vrp and MM1212/vRP-1. When you pick vRP as the target, the generator uses the API surface that the vRP server community actually runs today.

It depends. vRP is mature, stable, and still popular in EU and LATAM communities — especially where existing servers are already on it or on a vRPex variant. If you are building greenfield and have no prior commitment, QBCore or Qbox will give you a larger third-party ecosystem. If you are on vRP already or your content is vRP-specific, SwisserAI lets you keep building without rewrites.

Yes. The generator knows that vRP.* lives on the server and vRPclient.* lives on the client, that Tunnel.bindInterface registers a whole table of functions, and that Proxy.getInterface is the server-to-server shortcut. You will not see invented exports or ESX-style callbacks where Tunnel is the right answer.

Yes — paste the source and ask for a vRP rewrite. Money, inventory, and job logic map to vRP.giveMoney, vRP.giveInventoryItem, and vRP.hasGroup respectively. Note that some concepts do not translate cleanly (e.g. QBCore metadata items), so the output flags where manual review is needed instead of hallucinating a match.

vRP, without the hallucinated exports

Start with 250 free credits. Generate vRP-native scripts with real Tunnel/Proxy bindings.

Start Free See all frameworks