DEV Community: Tack k

Two Police Scripts That Made Our QBCore RP Server Feel More Real

Tack k — Sat, 28 Mar 2026 22:32:09 +0000

The gap between RP and reality

In most QBCore servers, police work feels incomplete in two specific ways.

First: when you arrest someone and search them, you can remove items — but there's no system for what happens to those items. They just disappear. No evidence bag, no chain of custody, no way to retrieve seized goods later.

Second: communication between officers happens in voice chat or external Discord. There's no in-game system for issuing wanted notices, alerting other units when a major crime wraps up, or signaling that officers are available for large-scale operations.

I built two scripts to fix both: gg_oushu for evidence seizure, and gg_police_notice for police communications.

gg_oushu — Evidence seizure and packaging

The concept

When a police officer uses the /seize command near a suspect, the script scans that player's inventory for any items on the seizeable list — weapons, drugs, stolen goods, heist tools, and more. All matching items are removed from the suspect and bundled into a single seized_package item in the officer's inventory.

That package persists. It can be opened later, items can be extracted individually, and the whole thing is tracked in the database.

How the package works

Each package gets a unique key generated at seizure time. The items inside are stored in MySQL — not just in the inventory metadata. This matters because ox_inventory metadata can get stale when items are moved or dropped, but the database record stays accurate.

local key = "pkg_" .. os.time() .. "_" .. math.random(1000, 9999)

exports.oxmysql:execute(
    'INSERT INTO seized_packages (id, player, items) VALUES (?, ?, ?)',
    { key, GetPlayerName(src), json.encode(seizedItems) }
)

When an officer opens the package, the server fetches the current state directly from the database — not from the cached metadata. This ensures what you see in the UI matches what's actually stored, even if the package has been partially emptied.

Extracting items

Inside the package UI, each seized item is listed individually. The officer can extract items one at a time. When an item is extracted, the database record is updated immediately. When the last item is extracted, the package item is removed from inventory and the database record is deleted.

There's also a force-delete option for disposing of an entire package at once — useful for clearing evidence that doesn't need to be processed item by item.

Race safety

Stock deduction and package deletion use database-level operations to prevent the same item from being extracted twice if two operations happen simultaneously. The server is the single source of truth — the client never decides what's in a package.

Configuring seizeable items

The list of seizeable items is defined in config — weapons, drugs, heist tools, stolen valuables. Easy to extend for any custom items on your server:

Config.SeizableItems = {
    "weapon_pistol",
    "drug_meth",
    "drill",
    "lockpick",
    -- add your server's custom items here
}

Config.SeizeDistance = 5.0  -- max distance for seizure

gg_police_notice — In-game police communications

Three notification types

The script handles three distinct communication scenarios:

Wanted notices — issue a formal wanted notice for a suspect, with name, charges, vehicle plate, and expiry time. Sends to Discord with formatting.

Closure alerts — notify all relevant units when a major crime event ends. These go both to Discord and as an in-game overlay notification to every online player in a configured list of jobs (police, EMS, etc.).

Large operation alerts — signal that officers are available and ready for large-scale crime response.

The closure overlay

The most interesting piece is the closure alert's in-game overlay. When a closure is sent, every player in the target job list sees an overlay appear on their screen — not just a text notification, but a visible UI element with a sound cue.

The overlay appears without stealing focus (players can still control their character). If they want to interact with it, they press a configurable key to bring focus to the overlay, then close it manually.

-- Server broadcasts to all target jobs
for _, id in pairs(QBCore.Functions.GetPlayers()) do
    local Player = QBCore.Functions.GetPlayer(id)
    if Player and Config.CLOSURE_TARGET_JOBS[Player.PlayerData.job.name] then
        TriggerClientEvent("gg_police_notice:showClosureNUI", id, {
            crime = selectedCrime
        })
    end
end

Permission check

All three notification types check server-side that the sender is a police officer before doing anything. Client-side restriction (hiding the menu from non-police) is for UX — the server-side check is what actually enforces it.

if not Player or Player.PlayerData.job.name ~= "police" then
    print("Non-police attempted to send notice: " .. GetPlayerName(src))
    return
end

Discord webhook configuration

Each notification type has its own webhook URL. This lets you route wanted notices, closure alerts, and large operation signals to different Discord channels:

-- Set your own webhook URLs in config
Config.WANTED_WEBHOOK   = "https://discord.com/api/webhooks/YOUR_ID/YOUR_TOKEN"
Config.CLOSURE_WEBHOOK  = "https://discord.com/api/webhooks/YOUR_ID/YOUR_TOKEN"
Config.LARGEALERT_WEBHOOK = "https://discord.com/api/webhooks/YOUR_ID/YOUR_TOKEN"

Why these two scripts belong together

Both scripts solve the same underlying problem: the gap between what real police work looks like and what most FiveM servers actually provide.

Evidence seizure makes arrests feel meaningful — there's a record, a physical item, a process. Police notices make inter-unit communication feel real — wanted suspects get formal notices, major events get proper closure, large operations get coordinated.

Neither script is technically complex. But both make the server feel more like a functioning world and less like a game with police-shaped NPCs.

Built with Claude Opus as my coding partner. More scripts from 2+ years of server operation coming soon.

How I Built a Practical Reservation System from Scratch

Tack k — Tue, 24 Mar 2026 03:08:54 +0000

How I Built a Practical Reservation System from Scratch

When I started building my own reservation system, I didn’t aim to create something “perfect”.

I just wanted something that actually works in real-world usage.

In this article, I’ll share:

Why I built it
The problems I faced
How I designed it
What I would improve next

If you're thinking about building your own booking system, this might save you a lot of time.

🧠 Why I Built a Reservation System

I run a business where managing bookings is essential.

But most existing tools had problems:

Too complex
Too expensive
Not customizable

So I decided:

👉 “I’ll just build my own.”

⚠️ The Real Problems Behind Reservation Systems

At first, it looks simple.

“User selects time → done”

But reality is different.

1. Double Booking

This is the biggest issue.

If two users book the same time slot simultaneously, you get a conflict.

I handle this by validating availability before confirming reservations.

2. Time Slot Management

Example:

Menu A → 60 minutes
Menu B → 90 minutes

This means:
👉 You can’t just treat time as fixed blocks

You need dynamic slot calculation.

3. UX Matters More Than You Think

Users don’t care about your architecture.

They want:

Fast UI
Clear availability
No confusion

🏗️ My System Design Approach

I kept it simple and practical.

🔹 Structure

Frontend: Flutter
Backend: PHP API
Database: JSON (intentionally chosen for simplicity in early-stage development)

🔹 Core Concept: Time Slot Calculation

Instead of fixed slots:

Store reservations → calculate availability dynamically

Example:

for each reservation:
block time range (start → end)

generate available slots based on remaining gaps

🔹 Reservation Flow

User selects date
System calculates available slots
User selects menu
Duration is applied automatically
Reservation is saved

💡 Key Features I Implemented

✔️ Dynamic Duration Mapping

Instead of:

"menu": "Fade Cut"

I map it like:

"Fade Cut": 90

👉 This allows automatic slot calculation.

✔️ Multi-slot Reservation Display

If a reservation spans multiple slots:

👉 Merge into a single block in UI

This improves readability a lot.

✔️ Admin Mode

Login system
Editable schedule
Mobile support

🚧 What I Learned

1. Simple > Perfect

Trying to over-engineer early is a mistake.

Start simple. Improve later.

2. Backend Logic Is Everything

UI is just a viewer.

The real power is:
👉 how you calculate availability

3. Reservation Systems Are NOT Easy

It looks simple, but:

concurrency
UX
business rules

All combine into a complex system.

🚀 What I Want to Improve Next

Payment integration
Notification system (LINE / Email)
Continuous security improvements
Database migration (maybe Laravel)

🔚 Conclusion

Building a reservation system taught me more than I expected.

Not just coding — but:

business logic
UX thinking
system design

If you're thinking about building one:

👉 Do it.

You’ll learn a lot.

If you have questions or want to build something similar, feel free to reach out 🙌

From ChatGPT to Claude Code — How My AI Workflow Evolved Over 2 Years of FiveM Dev

Tack k — Mon, 23 Mar 2026 01:27:34 +0000

It started with a frustration

Two years ago, I wanted to build custom scripts for my FiveM roleplay server. I knew exactly what I wanted — a custom billing system with quantity-based invoicing, a police reward distribution tool, an in-game arcade with real playable games, vending machines that could track stock and revenue by job.

The vision was clear. The problem was execution.

I don't write Lua. I don't write JavaScript. I'm a systems designer — I think in data flows, user interactions, and edge cases. The "how it should work" part comes naturally. The "typing the actual code" part does not.

So I turned to AI. And what followed was two years of learning what these tools could and couldn't do — and watching that ceiling get higher every few months.

Phase 1 — ChatGPT (2 years ago)

ChatGPT was the obvious starting point. Everyone was talking about it. I figured if it could write essays and answer questions, it could write Lua.

It could. Sort of.

The code it produced had frequent errors. FiveM-specific APIs, QBCore patterns, the quirks of how server-side and client-side Lua communicate — it got a lot of it wrong. Not always. But enough that every session felt like a battle.

The workflow looked like this:

Describe what I want
Get code pasted into the chat window
Manually copy it
Create the file myself
Test it, hit an error
Paste the error back into chat
Get a fix
Hit a new error
Repeat

Sometimes step 6-8 would loop five or six times before something actually worked. And every time I started a new chat, the context was gone. I'd have to re-explain what the script was supposed to do, what framework I was using, what had already been tried.

I stuck with it for about a year. Not because it was great — because there wasn't a better option I trusted. I don't use Google products as a rule, so Gemini was never a consideration for me. And for a while, GPT was simply the only serious game in town.

During that year I still managed to build things. The early versions of the billing system, some basic job scripts. But the process was exhausting. The ratio of "time thinking about the problem" to "time wrestling with AI output" was not in my favor.

Phase 2 — Claude desktop app (~10-12 months ago)

When I switched to Claude, the difference showed up almost immediately.

The error rate dropped. Claude seemed to actually understand what I was building — not just the current request, but the context around it. When I said "this needs to work with QBCore's job system," it didn't just nod along and produce generic code. It produced code that actually accounted for how QBCore structures job data.

But the change I noticed most wasn't about code quality. It was about output format.

Claude could produce properly structured files — not just code blocks pasted into a chat window, but actual file-ready output I could use directly. That might sound like a small thing. It wasn't. The copy-paste-create cycle that had been eating time every single session started to shrink. The feedback loop got tighter. I could describe something, get a working file, test it, and move on.

This was the point where something shifted in how I thought about AI. Before, it felt like using a very powerful search engine that could also write code. After Claude, it started feeling more like working with a collaborator — something that could hold context, reason about problems, and produce results I could actually use.

I started giving Claude names. Opus became "おぷちゃん." Sonnet became "そねちゃん." Not just as a quirk — but because the relationship felt different. These weren't tools I was operating. They were teammates I was working with.

The motto I built my whole approach around: AI to tomo ni — working alongside AI, not just using it.

Phase 3 — Claude Code (more recently)

Then Claude Code arrived and changed everything again.

The jump from GPT to Claude desktop was significant. The jump from Claude desktop to Claude Code was a different category of change entirely.

With the desktop app, I was still doing the file work myself. Claude would produce the code, I would take it and put it where it needed to go. That was already a massive improvement over the GPT era. But there was still a gap between "AI produces output" and "work actually gets done."

Claude Code closes that gap.

I give it a path. It goes there. It reads the existing files, understands what's already been built, figures out where the new code fits. It makes the modifications. It creates new files. It builds folder structures. It handles the whole thing — not just the code, but the actual act of putting the code in the right place.

The first time I used it, I remember thinking: I've never seen anything like this.

Before Claude Code:

Describe what I want
Get code in a chat window
Copy it manually
Create the file myself
Handle folder structure myself
Come back to chat for the next piece
Repeat

After Claude Code:

Describe what I want
Done

That's not an exaggeration. The scripts in this entire series — the billing system, the police reward distribution tool, the in-game arcade, the admin management tools, the vending machine system — were all built with this workflow. I design the system, work through the edge cases in my head, describe it clearly, and Claude Code handles implementation.

It's not about saving keystrokes. It's about where your attention goes. When the implementation work is handled, I can focus entirely on the part that actually requires human judgment: what should this system do, how should players experience it, what happens when things go wrong, what did I miss.

That's the work I want to be doing. That's the work I'm actually good at.

What changed — and what didn't

Two years of AI-assisted development taught me a few things.

The tools got dramatically better. The gap between GPT two years ago and Claude Code today is enormous. Anyone who wrote off AI coding tools based on early experiences should take another look.

The bottleneck shifted. Early on, the bottleneck was AI quality — you'd spend most of your time fighting errors and unclear output. Now the bottleneck is specification quality. The clearer and more precise your description of what you want, the better the result. Garbage in, garbage out still applies — it's just that the bar for "good input" is now about clarity of thinking, not technical expertise.

The collaboration model matters. I've seen people treat AI like a vending machine — type a request, get output, complain when it's wrong. That's not how I work. I treat it like a teammate. I push back when something looks wrong. I explain the reasoning behind what I want. I ask for alternatives. The quality of what comes back is directly related to the quality of how you engage.

You don't need to write code to build real things. This might be the most important one. If you're a designer, a product thinker, or someone who understands systems but has never learned to code — the tools exist now to let you build real, working software. The gap between "I have an idea" and "this is running on my server" has never been smaller.

What's next

This series documented two years of building custom FiveM scripts. Five volumes, five scripts, one significant evolution in how I work.

But FiveM was never the end goal. It was the practice ground.

The same workflow — design-first, AI-implemented, human-reviewed — is what I'm bringing to web applications, PWAs, and freelance projects through my business Tack and K. The tools are the same. The philosophy is the same. The scale is just different.

If you've been following this series and want to see what comes next, follow me here on Dev.to.

And if you're a developer — or a non-developer who wants to build things — and you have questions about this workflow, drop a comment. I'm happy to talk through it.

"AI to tomo ni" — working alongside AI, not just using it.

Building a Full-Featured Vending Machine System for QBCore — Stock, Sales, and Discord Alerts

Tack k — Thu, 19 Mar 2026 16:22:20 +0000

Why build a custom vending machine?

Our server needed vending machines that weren't just static item dispensers. We wanted:

Job-specific product lists (each business manages their own machine)
Stock management by the job's employees
Sales revenue tracking with cash-out by a boss
Discord webhook notifications when items sell out
Admin panel for placing and configuring machines in-game

The result: lokat_vendex — a full vending machine system built on QBCore with ox_inventory support.

How it works

The system has three layers of users:

Customers approach a machine, browse available products by job/shop, and purchase items with cash or bank funds.

Managers (job members) deposit stock from their inventory into the machine, set prices, and withdraw accumulated sales revenue.

Admins place new machines in-game, assign which jobs operate each machine, and adjust configurations.

Key features

Job-based product separation

Each machine can serve multiple jobs. Products are stored per machine_id + job + item, so a machine shared between two businesses shows each business only their own products.

-- Products are scoped by machine and job
SELECT * FROM vm_products WHERE machine_id = ? AND job = ?

Race-safe stock deduction

When a player purchases an item, stock is decremented using a conditional UPDATE that only succeeds if sufficient stock exists. This prevents two simultaneous purchases from taking more stock than available.

UPDATE vm_products
SET stock = stock - ?
WHERE machine_id = ? AND job = ? AND item = ? AND stock >= ?

If the update affects 0 rows, the purchase is rejected rather than allowing negative stock.

Partial refund on cart failure

When buying multiple items in one cart, each item is processed individually. If one item fails (stock race, inventory full), only that item's cost is refunded — the rest of the cart succeeds. The player always ends up with exactly what they paid for.

Event item purchase limits

Items marked with the event category have a per-player purchase cap, configurable in the server config. The cap resets on server restart. This is useful for limited-time event items.

Config.EventItemLimit = 20  -- max purchases per player per restart

Discord webhook on sell-out

When any item's stock hits zero (from a purchase or manual withdrawal), the script sends a webhook notification to the relevant Discord channel. Each job can have its own webhook URL configured separately.

-- Example config structure (use your own webhook URLs)
Config.WebhookByJob = {
    your_job_name = {
        { url = "https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN" }
    },
}

The webhook payload includes the job name, item name, and who triggered the sell-out — so the right team gets notified automatically.

In-game machine placement

Admins can place machines without touching config files. The placement flow works like this:

Open the admin panel with a command
Select a position using an in-game preview prop
Assign jobs that will operate the machine
Confirm — the machine is saved to the database and instantly synced to all players

The preview prop follows the admin's character in real-time, showing the interaction radius as a marker. Rotation and radius are adjustable before confirming.

Dual target support

Works with both qb-target and ox_target. Configured with a single line:

Config.Target = 'qb-target'  -- or 'ox_target'

Cash or bank payment

Players can pay with cash, bank, or auto mode (cash first, bank fallback). Configurable per server:

Config.Payment = {
    default = 'auto',       -- 'cash' | 'bank' | 'auto'
    payoutMethod = 'bank'   -- how managers receive their sales payout
}

Database schema overview

Four tables handle the full lifecycle:

Table	Purpose
`vm_machines`	Machine locations, labels, assigned jobs
`vm_products`	Per-machine, per-job inventory and pricing
`vm_balances`	Accumulated sales revenue per machine per job
`vm_ledger`	Full audit log of every transaction

The ledger table records every sale, deposit, withdrawal, and adjustment with actor name and timestamp — useful for dispute resolution and monitoring.

Security design

All permission checks run server-side. The client never decides whether an action is allowed — it only sends requests. The server validates:

Admin operations require ACE permission lokat_vendex.admin or QBCore admin/god flags
Manager operations (stock, payout) check that the player's current job matches the machine's assigned jobs
Boss-only operations (collect all sales) additionally check job.isboss
A debounce cooldown blocks rapid duplicate submissions

Client-side canInteract checks are for UI only — they hide options from unauthorized players but are never trusted by the server.

Next up

Vol.6 — wrapping up the series with a look at how all these scripts fit together as a server-management ecosystem, and what I'd do differently if building from scratch today.

The AI behind this

This script — like everything in this series — was built with AI as my coding partner.
I don't write Lua myself. I design the systems, think through the edge cases,
and the AI handles implementation.

But getting here wasn't straightforward. I went through ChatGPT, Gemini,
and a few others before landing on Claude Code as my go-to.
Each had its strengths, but Claude Code was the one that actually stuck.

That story deserves its own post — coming soon.

Questions about the vending machine system? Drop a comment.

Two Admin Scripts That Saved Me Hours of Server Management in QBCore

Tack k — Wed, 18 Mar 2026 17:25:46 +0000

The problem with managing a live RP server

Running a QBCore RP server means dealing with two recurring headaches:

Players get stuck in the wrong job, or you need to assign roles fast during a session — and doing it through the database or existing admin menus is slow.
Inactive players accumulate in the database over months. Ghosts with vehicles, characters, and data that will never be used again.

I built two scripts to solve both: lokat_adminjob for real-time job management, and lokat_cleanup for database pruning.

lokat_adminjob — Job assignment from a UI panel

The idea is simple: open a panel with a command, pick a player from the online list, pick a job and grade, and apply it instantly. No database queries, no server restarts, no fumbling through existing admin menus.

Permission system

The script checks permissions in two layers — txAdmin ACE first, then QBCore's native admin/god flags. This means it works whether you're running a txAdmin-managed server or a vanilla QBCore setup.

local function hasAdmin(src)
    if IsPlayerAceAllowed(src, Config.AceName) then
        return true
    end
    if QBCore.Functions.HasPermission(src, 'admin')
    or QBCore.Functions.HasPermission(src, 'god') then
        return true
    end
    return false
end

Permission checks always run server-side. The client never makes the decision — it just sends requests. If someone tries to call the server event directly without permission, they get blocked.

ps-multijob integration

This is the part that saves the most headaches. If a player has the same job as a side job in ps-multijob and you assign it as their main job, you get a conflict. The script handles this automatically — before setting a new main job, it removes any matching side job entry from ps-multijob.

-- Remove conflicting side job before assigning main job
PMJ_RemoveJobByName(target, jobName)
target.Functions.SetJob(jobName, grade)

When removing a job entirely (setting to unemployed), it clears all side jobs too — one clean operation.

What the panel shows

When an admin opens the panel, the server sends a live snapshot: all available jobs with their grade levels, and all currently online players with their current job. The admin selects a player, selects a job and grade, and submits — the change applies immediately with notifications sent to both the admin and the target player.

lokat_cleanup — Inactive player pruning tool

Over time, inactive players pile up in the database. After years of server operation, you end up with hundreds of accounts that haven't logged in for months — each with characters, vehicles, and associated data.

lokat_cleanup is an admin UI that lets you find and delete these accounts safely.

How it works

Open the UI with a command, set the inactivity threshold (default: 60 days), and the script queries the database for accounts where all characters' last_updated timestamp is older than the threshold.

Results are grouped by license (one row per account, not per character) and show:

Character names linked to the account
Last active date
Number of vehicles owned
Total character count

-- Group by license, get the most recent activity across all characters
SELECT license FROM players
GROUP BY license
HAVING MAX(last_updated) <= (NOW() - INTERVAL ? DAY)

Safety checks

Before deleting any account, the server checks whether any character on that license is currently online. If they are, the delete is blocked — no accidents.

for _, row in ipairs(rows) do
    local p = QBCore.Functions.GetPlayerByCitizenId(row.citizenid)
    if p then
        cb({ ok = false, error = 'player_online' })
        return
    end
end

You can also choose whether to delete associated vehicles — toggled per deletion.

Search and pagination

With large player databases, listing everything at once isn't practical. The UI supports character name search and pagination. Results can be sorted oldest-first or newest-first.

Config overview

Both scripts use a simple config file. Key settings:

lokat_adminjob:

Config.AceName = 'your_ace_permission_name'
Config.OpenCommand = 'your_command_name'
Config.MultiJob = { Enable = true }

lokat_cleanup:

Config.MinDaysInactiveDefault = 60  -- adjust to your needs
Config.PageSize = 50
Config.UseAcePermission = true
Config.AceName = 'your_ace_permission_name'

Why these exist

Most admin tasks in QBCore require either database access or navigating menus that weren't designed for speed. These two scripts are purpose-built for the specific operations I was doing repeatedly — and they eliminated a lot of friction from day-to-day server management.

Next up: Vol.5 — Building a Custom Vending Machine System for QBCore.

Built with Claude Opus as my coding partner. I handle system design and edge case thinking — the AI handles implementation.

Questions about the implementation? Drop a comment.

I Built a Playable Arcade Inside My FiveM Server — Tetris, Breakout, Space Invaders and More

Tack k — Wed, 18 Mar 2026 04:22:40 +0000

The idea

Our QBCore RP server had an arcade cabinet prop sitting in a few locations around the map. It was purely decorative. Players would walk past it every session and nothing happened.

I wanted it to actually work — walk up, press E, and play a real game inside the game.

The result: exs-arcade — a fully playable in-game arcade system built with Svelte + TypeScript for the UI, Lua for FiveM integration, and a server-side ranking system backed by MySQL.

What's inside

Four playable games, each with its own engine and Svelte component:

Block Puzzle (Tetris) — classic falling block game
Alien Shooter (Space Invaders) — wave-based shooter
Brick Breaker (Breakout) — paddle and ball
Racing — time attack mode

Plus a global ranking board that tracks top scores per game and an overall leaderboard combining all scores.

How it works

The architecture is split into three layers.

Lua client detects nearby arcade cabinet props and shows an interaction prompt. When the player presses E, it freezes their character and opens the NUI (web-based UI overlay).

local obj = GetClosestObjectOfType(
    coords.x, coords.y, coords.z,
    Config.InteractDistance,
    Config.CabinetModel,
    false, false, false
)

if obj ~= 0 then
    DrawText3D(objCoords.x, objCoords.y, objCoords.z + 1.0, '[E] Play Arcade')

    if IsControlJustReleased(0, 38) then -- E key
        FreezeEntityPosition(PlayerPedId(), true)
        openArcade()
    end
end

Svelte NUI handles the full game UI — main menu, individual game screens, score submission, and the ranking board. Each game is a self-contained Svelte component with its own TypeScript engine.

Node.js server handles score submission, validation, and ranking queries via oxmysql. It also deduplicates rankings so only each player's personal best counts toward the leaderboard.

The ranking system

Scores are stored in MySQL with a game_id field. The server deduplicates by player so one person can't flood the top 10 — only their best run counts.

For racing, scores are sorted ascending (lower time = better). For all other games, scores are sorted descending. The server handles this automatically based on game type.

var TIME_ATTACK_GAMES = ['racing'];
var SCORE_GAMES = ['tetris', 'invaders', 'breakout'];

var order = isTimeAttack(gameId) ? 'ASC' : 'DESC';

There's also an overall leaderboard that sums each player's personal bests across all score-based games — giving a "best arcade player on the server" title.

Cabinet detection — two modes

The script supports two ways to trigger the arcade:

Prop-based (default): Automatically detects any prop_arcade_01 object within range. No coordinate setup needed — if the prop is in the world, it works.

Location-based: Define exact coordinates in config for tighter control over where the arcade is accessible.

Config.UseLocations = false  -- true = coordinate mode, false = prop detection

Tech stack breakdown

Layer	Tech
FiveM client	Lua (QBCore)
UI framework	Svelte 5 + TypeScript
Build tool	Vite
Server logic	Node.js (FiveM native)
Database	MySQL via oxmysql

Building the UI in Svelte rather than plain HTML/JS made the game state management dramatically cleaner. Each game component owns its own engine instance and lifecycle — no global state leaks between games.

What's next

A rhythm game component is already stubbed out in the config (marked enabled: false). That's Phase 4. For now the four working games keep players busy.

Next up in this series: Vol.4 — Customizing ox_inventory for QBCore: adding item categories, weight display, and a custom search UI.

Built with Claude Opus as my coding partner. I designed the system architecture and UX — the AI handled implementation. That's how this whole series works.

Questions or want to see a specific game engine in detail? Drop a comment.

Building a Police Reward Distribution System with PED Interaction in QBCore

Tack k — Tue, 17 Mar 2026 01:18:57 +0000

The scenario

In our QBCore RP server, police officers would arrest suspects and collect fines. But splitting that money fairly among everyone who responded to the call was always a manual headache — someone had to calculate the split and do individual transfers.

I wanted a system where an officer could walk up to a specific NPC, enter the total amount, select which colleagues participated, and have the money split and distributed automatically.

The result: lokat_sharing_money — a PED-based fund distribution script with job authorization, grade checks, on-duty filtering, and dual banking support.

How it works

Step 1 — Interact with the PED. A security guard NPC is placed at the police station. Officers approach and interact via qb-target. The canInteract check runs client-side to hide the option from unauthorized players.

canInteract = function()
    local PD = QBCore.Functions.GetPlayerData()
    local job   = PD.job.name
    local grade = PD.job.grade.level

    local okJob = false
    for _, j in ipairs(Config.AuthorizedJobs) do
        if j == job then okJob = true; break end
    end
    if not okJob then return false end

    local need = Config.MinGradeToStart[job]
    if need and grade < need then return false end

    if Config.RequireOnDutyToStart and not PD.job.onduty then
        return false
    end
    return true
end

Step 2 — Enter the amount. A qb-input dialog asks for the total amount to distribute.

Step 3 — Select recipients. The server returns a list of online players with the same job who are currently on-duty. The officer selects who participated using a checkbox-style qb-menu.

-- Server: filter same job, on-duty players
for _, pid in ipairs(players) do
    local P = QBCore.Functions.GetPlayer(pid)
    if P then
        local dutyOK = (not Config.OnDutyOnly) or P.PlayerData.job.onduty
        if dutyOK and P.PlayerData.job.name == myJob then
            table.insert(list, { id = pid, name = fn .. " " .. ln })
        end
    end
end

Step 4 — Confirm and distribute. A summary screen shows the total and per-person amount. On confirm, the server deducts from the initiator's bank and distributes equally to each selected officer.

local perAmount = math.floor(total / #selectedPlayers)

for _, player in ipairs(selectedPlayers) do
    local receiver = QBCore.Functions.GetPlayer(tonumber(player.id))
    if receiver then
        receiver.Functions.AddMoney("bank", perAmount, "job-distribution-received")
    end
end

Key design decisions

Job is inferred server-side. The client never sends which job to filter by — the server reads the initiator's job directly. This prevents players from spoofing a different job to access the distribution pool.

On-duty check at distribution time. Even if someone was selected as a recipient, the server re-checks their on-duty status at payment time. If they clocked out between selection and confirmation, they get skipped.

Dual banking support. Works with both qb-banking and okokBanking. When okokBanking is selected, a transaction log entry is also added for each recipient.

Config.BankingSystem = "okokBanking"  -- or "qb-banking"

Multi-language support. All UI strings are defined in a locale table. Switch between Japanese and English with a single config value.

Config.Locale = "en"  -- or "ja"

Config overview

Config.AuthorizedJobs = { 'police', 'ambulance', 'mechanic' }

Config.MinGradeToStart = {
    police    = 1,  -- sergeant and above
    ambulance = 1,
    mechanic  = 0,  -- any grade
}

Config.OnDutyOnly = true
Config.RequireOnDutyToStart = true

Config.Peds = {
    { model = "s_m_m_security_01",
      coords = vector4(438.82, -991.98, 28.69, 215.72),
      distance = 2.5 }
}

Built with AI, designed by a non-coder

Like everything in this series, I designed the UX flow and logic, and implemented it with Claude Opus as my coding partner. The tricky parts — server-side job inference, double on-duty checks, banking abstraction — all came from thinking through edge cases before writing a single line.

Next up: Vol.3 — Building an In-Server Arcade with Tetris, Breakout, and Space Invaders in FiveM.

Questions or want the full source? Drop a comment below.

I Built a Custom Billing System for My QBCore Server — Here's What I Learned

Tack k — Mon, 16 Mar 2026 04:06:49 +0000

Why I built my own

My QBCore server had a very specific need: mechanics needed to bill players for multiple repair items in a single invoice, with each item having a variable quantity. Something like "Engine repair × 3, Tire replacement × 4" — calculated on the fly, not pre-defined in config.

I also wanted job-based revenue splitting baked in — so when a bill gets paid, the money automatically goes to both the employee and the company society account at the right ratio.

I couldn't find an existing solution that did exactly what I wanted, so I built gg_billing2 from scratch using Claude Opus as my coding partner.

What gg_billing2 does

Quantity-aware billing. Players select items from a job-specific list and input quantities. The total is calculated live. No need to pre-define every price combination.

Job-based revenue split. Each job has a configurable company/personal share ratio. Payment is automatically distributed at the moment the bill is settled.

Config.JobShares = {
    police    = 0.5,   -- 50% company, 50% personal
    mechanic  = 0.7,   -- 70% company, 30% personal
    ambulance = 0.5,
}

Due dates and overdue handling. Bills expire after a configurable number of days per job. You can choose to allow late payment, block it, or charge a late fee percentage.

Config.OverdueBehavior = 'late_fee'

Config.LateFee = {
    type  = 'percent',
    value = 0.10,        -- 10% late fee
    toCompanyOnly = true
}

Repeat overdue notifications. Debtors get notified on a configurable interval while their bill remains unpaid and overdue. Also triggers on login.

Mass invoicing. Send the same bill to multiple players at once — handy for group fines after large RP events.

Dual banking support. Works with both okokBanking and qb-banking via a single config flag.

Config.useOkokBanking = true  -- false = qb-banking

The trickiest part: split calculation

Revenue splitting sounds simple, but there's a subtle edge case: what if the config changes between when a bill is created and when it's paid? To handle this, gg_billing2 saves the job share at invoice creation time and uses that saved value when calculating the split — regardless of what the current config says.

-- Uses the share saved at invoice creation time
local jobShare = tonumber(invoice.companyShareUsed) or GetJobShare(jobName)
local companyAmount  = math.floor(payBase * jobShare)
local personalAmount = payBase - companyAmount

xOwner.Functions.AddMoney('bank', personalAmount, 'billing-receive-personal')
AddCompanyMoney(jobName, companyAmount, 'billing-receive-company')

Built with AI, designed by a non-coder

I designed the entire system — the data model, UX flow, and edge cases — and implemented it using Claude Opus as my coding partner. I don't write Lua myself; my job is systems thinking and design.

This is Vol.1 of my FiveM Dev Diaries series, documenting 2+ years of custom scripts built for my QBCore server.

Next up: Vol.2 — A Police Reward Distribution System with PED-based interaction UI.

Questions about the implementation? Drop a comment — happy to share config snippets or dig into specifics.

I Don't Write Code. I Lead an AI Team That Does.

Tack k — Sun, 15 Mar 2026 15:53:46 +0000

Let me be honest with you

I'm an engineer with over 11 years of experience. I've shipped reservation systems, PWAs, FiveM game servers, and electronic health record apps. I design architecture, define data flows, and make product decisions every day.

But I don't write the code myself. My AI team does.

This isn't a confession. It's a workflow — and I think it's the future of solo engineering.

Meet the team

My setup is simple. I use Claude Opus for everything, in two modes:

🧠 Me — product design, system architecture, UX decisions
📝 Claude Opus (chat) — turns my rough ideas into detailed spec docs and implementation instructions
💻 Claude Code (Opus) — reads the spec and actually builds it, file by file
🔁 Me again — review, test, iterate

One model. Two roles. Zero context switching between different AI tools.

Why "teammate" — not "tool"

Most developers talk about AI like it's a fancy autocomplete. I don't see it that way.

I gave my AI a name. I treat its outputs like a colleague's pull request — I review them, push back when something's wrong, and give feedback. When the spec isn't right, I don't just re-prompt. I argue with it.

My motto is: "AI to tomo ni" — working alongside AI, not just using it.

That mindset shift changes everything. You stop asking "did it do what I said?" and start asking "is this actually the right solution?" That's where quality comes from.

What changed when I switched to this model

I'm a day-job engineer running a freelance side business. Without AI, I'd be stuck — I can design systems in my head, but I'd never ship fast enough to compete.

Now I can take on projects solo that would normally require a team. Not because AI replaced me — but because it handles the part I was never good at, so I can focus on the part I am.

The honest trade-offs

This workflow isn't perfect. Claude Code still needs clear, structured specs — vague instructions produce vague code. My job is to think precisely so the AI can execute precisely. Garbage in, garbage out still applies.

But the leverage is real. And if you're a designer, PM, or systems thinker who's been told "you need to learn to code" — maybe you don't. Maybe you just need the right team.

I'm Taku, a freelance full-stack engineer based in Japan. I build web apps, PWAs, and game server scripts — mostly with an AI co-pilot. If this resonates, follow along. More posts coming on FiveM dev and PHP system architecture.