Admin Settings

ALPR & the Plate Reader

The CAD can alarm an officer when the plate reader in their car picks up a vehicle that is wanted, stolen, uninsured, or whose owner should not be driving.

There is no ALPR page in the dashboard. This one is configured in config.lua in the resource package, not in the CAD — so it is a file edit and a resource restart rather than a setting you flip. What you do manage in the CAD is the data it alarms on, which is covered further down.

What you need installed

The reader itself is not ours: LUX CAD hooks into wk_wars2x, the radar resource most servers already run. Without it there is no scanning at all — the manual lookup in the MDT still works, but nothing alarms from the car.

Start the radar resource in your server.cfg alongside lux-cad. Nothing else needs wiring: the CAD listens for the radar's own scan and lock events.

The three settings

All three live in config.lua. To change one and keep the change through updates, set it in config-custom.lua instead — see Your own settings.

WkAlprAutoLock is about who makes the noise. Left on, the radar locks the plate on screen and plays its native BOLO tone, and the CAD suppresses its own beep so the two do not stack. Turn it off and the radar is left alone: you get only the CAD's card and sound. Turn it off if your officers use the radar for speed enforcement and do not want a lock jumping in mid-measurement.

FlaggedVehicleRefreshMs is a lag, not a speed. Vehicle status, insurance and license changes are not pushed to the game server, so it polls for them. That interval is the worst case between marking a plate in the CAD and it alarming in-game. BOLOs are different — those are broadcast the moment they go out and arrive immediately.

Lower it and every server polls more often for a gain most communities never notice; the floor is 10 seconds and anything below it is treated as 10. Note the poll is skipped entirely while nobody is on the server, so an empty server costs nothing regardless of what you set.

What it alarms on

The reader has no list of its own. Everything it reacts to is data your community already keeps in the CAD:

A BOLO takes precedence: if the plate is on one, that is the alert, with the BOLO's narrative as the reason. Everything is scoped to your community — another community's stolen car is not yours.

Two limits worth knowing before somebody reports them as bugs:

• Only on-duty units get alerts. Someone driving a patrol car without signing on as a unit scans nothing.
• A warrant on the owner does not alarm passively. It shows up when an officer locks a plate by hand, which returns the full record — owner, record status, registration and insurance — but the passive scanner does not raise it on its own.

What you cannot set for your community

Which alerts an officer sees is their own setting, per person and per device, in Settings → ALPR settings. There is no community-wide override and no way to force one on. If a specific alert is not reaching one officer, the setting is on their machine — see ALPR & Plate Alerts.

The same goes for the alert volume: each user sets it under Sound levels. See Your Settings.

When it does not fire

Work down this list before assuming the integration is broken.

1. Is the radar resource running? Check the server console at start-up.
2. Is EnableWkAlpr still true in the config.lua that is actually deployed — not the one in your download folder — and not set to false in your config-custom.lua?
3. Did you restart the resource after editing? config.lua is read at start.
4. Is the officer signed on as a unit?
5. Is the plate actually flagged in the CAD, and did you wait out the refresh interval?
6. Is the plate the same string? Spacing is ignored, but a vehicle registered under a different plate than the one on the car will never match.