Robbery locations fall into two useful groups: recognizable fixed sites such as the bank and jeweler, and state-dependent targets such as containers, safes, cash registers, and vending machines. Reaching the right type of place is only the first step; the live interaction confirms whether a robbery is available.
Location index
Use fixed sites as anchors
Learn the road network around the bank and jeweler even when you are not robbing them. Their recognizable buildings help orient a route. Approach through normal streets and identify multiple exits before interacting.
Fixed location does not mean permanent availability. Cooldown, prior use, server state, and update changes can affect the objective.
Search state-dependent targets
Area
Choose a target zone
Use map context and maintained references to define a small search area rather than checking the entire city.
Object
Look for the live prompt
A matching model without an interaction may be decorative or unavailable.
State
Record server and date
A valid target observation may not repeat after another player, cooldown, or server change.
Pair location with the correct guide
Open Bank, Jeweler, Container, Safe, Cash Register, or Vending Machine after identifying the target. Each page separates preparation, interaction, and result checks.
Avoid stale location claims
Record the check date, nearby fixed landmark, accessible route, and the current prompt. Do not publish exact coordinates inferred from a screenshot. Do not use teleport scripts or clipping to prove a target exists.
The maintained Locations reference and Robberies reference support this location structure. The current server controls availability, prompts, items, cooldowns, and results.
Scout without starting the objective
Visit fixed sites as a citizen and learn the normal doors, surrounding roads, and places where large vehicles struggle. For smaller targets, walk the commercial or industrial area and record which objects display a live prompt. Scouting should use ordinary access and should not consume an item or trigger a wanted state.
Mark at least two departure directions for a major building, but do not call either safe. Traffic, police, other players, and server state can change the scene. A good route gives options and clear turns rather than an exploit-dependent hiding place.
Location freshness record
For every target report, include the check date, game update context, server type, nearest fixed landmark, normal approach, target appearance, and live prompt. Keep availability separate from location. The bank building can remain fixed while its robbery is unavailable; a register can remain visible while it has no active interaction.
If a target moves after an update, verify the new route from a stable anchor before replacing the old note. If one server lacks the target, label that observation without claiming removal.
Troubleshoot an empty site
Allow the map and objects to load, confirm the correct building or area, inspect the intended interaction position, and check whether another player is using the target. Try one other known target or one fresh server. Stop after that bounded test. Clipping through doors, teleporting, or running a scanner is not evidence of a supported player location.
Pair the route with current state
When a player reaches the correct site but finds no prompt, record “location confirmed, target unavailable” rather than “wrong location.” When a prompt appears at a new object within the same site, update the target description without creating a duplicate route. This distinction prevents map guidance from being rewritten every time a cooldown or server state changes.
Check the final route on foot and by vehicle. Entrances, parking, turning room, and the current target prompt must all be reachable through ordinary play.