Car Boosting and Navigation Pre-Live Test Plan

This plan is the release gate for the Car Boosting, MESKA, lockpick, hotwire, engine hint, F1 map, minimap, compass and road-routing work on release/20260730.

Do not run destructive database checks or promote these changes from a live branch. Use a development server, a beta database copy and the beta directory of service-map.

Exit criteria

A release candidate may move to live only when:

• every Critical and High case passes;
• no new client or server Lua errors appear during a two-hour soak;
• no MESKA foreign-key, nil-index or duplicate-registration errors appear;
• non-staff cannot execute any waypoint administration command;
• cold and warm F1 loads succeed in the in-game DHTML panel;
• the minimap route stays aligned during the full driving route;
• Boosting completes once in every contract class;
• reconnect and server-restart persistence checks pass;
• the database backup and rollback owner are recorded; and
• QA, development and server operations sign off the same candidate commits.

Any Critical or High failure blocks release. A Medium failure requires a written acceptance decision and owner. Cosmetic Low failures may be scheduled after release only when they do not obscure instructions, navigation or timers.

Candidate record

Record this before testing:

Field	Value
CityRP branch	release/20260730
CityRP commit
service-map branch	master
service-map commit
Web scope	beta only
Map	rp_evocity_v4b1_fl2
Road JSON checksum
Game server
Beta database
Tester
Start and finish

Required test coverage

Use:

• a clean player with no Boosting MESKA paths;
• an existing player with Boosting XP and achievements;
• an RP Assistant;
• a higher staff rank;
• a normal player with no staff access;
• two crew members;
• a player connected before a scripted hot reload;
• default, small and disabled minimap states;
• compass enabled and disabled;
• 1920×1080, 2560×1440 and an ultrawide resolution;
• the minimum and maximum supported HUD scale;
• cold DHTML and map-material caches;
• warm DHTML and map-material caches;
• driver, passenger and on-foot states; and
• player-owned and system-generated Boosting targets.

Capture the client console, server console, relevant database rows, screenshots and profiler samples. Label evidence with the case identifier below.

1. Deployment and startup

DEP-01 — Branch and scope guard

Priority: Critical.

1. Confirm the game checkout is release/20260730.
2. Confirm no live or production branch is checked out.
3. Confirm every service-map change is below beta/.
4. Confirm no production URL or database credential was added.

Expected: only the intended development branch and beta web content are modified.

DEP-02 — Clean server startup

Priority: Critical.

1. Start a development server with the beta database.
2. Capture the full startup log.
3. Join once with a normal player and once with staff.

Expected:

• no Lua errors;
• no failed SQL queries;
• MESKA completes setup;
• Waypoints reports a loaded graph with 1,323 nodes;
• Car Boosting loads once;
• no duplicate network-string, hook or timer warnings; and
• meska_metrics_meska_skills_name_fk does not fail.

DEP-03 — Hot reload safety

Priority: High.

1. Keep one existing player connected.
2. Hot reload the Car Boosting and Waypoints code through the normal development workflow.
3. Open Skills, F1 Map and the minimap.
4. Start and finish one D-class contract.

Expected: the connected player receives missing Boosting paths without reconnecting; no MESKA nil-index occurs; UI hooks and timers are not duplicated.

2. F1 map

MAP-01 — Cold load and layout

Priority: Critical.

1. Clear the DHTML cache using the approved development procedure.
2. Press M.
3. Open the Map tab at every required resolution.

Expected:

• the beta map image loads;
• Categories remain above the location list;
• location rows do not overlap the footer;
• the map surface outside the artwork is #1a1a1a;
• controls remain visible;
• the full artwork fits after reset; and
• the console contains no HTML, JavaScript or material errors.

MAP-02 — Exact projection alignment

Priority: Critical.

1. Stand at five widely separated surveyed locations, including both extreme sides of the map.
2. Compare the F1 player arrow, minimap centre and corresponding F1 pin.
3. Repeat in a vehicle.

Expected: all three use WorldToMapUV against the same 3896×4096 artwork. No location has progressive X or Y drift toward the image edges.

MAP-03 — Pin selection and centring

Priority: High.

1. Click a visible map pin.
2. Click the matching location row.
3. Click its Set waypoint button.
4. Repeat after panning and at minimum and maximum zoom.

Expected: each action selects the same item and moves the pin anchor to the viewport centre. The selected row is scrolled into view. No browser focus or white outline is drawn around the pin.

MAP-04 — Pin clarity

Priority: High.

1. Inspect several pin colours at reset, medium and maximum zoom.
2. Pan while zoomed.
3. Compare stationary and moving frames.

Expected: pin artwork remains sharp and constant in screen size, does not flicker, and stays anchored to its world position.

MAP-05 — Pan, zoom and reset

Priority: Medium.

1. Drag the map in every direction.
2. Use mouse-wheel zoom and all three control buttons.
3. Reset after selecting a pin.

Expected: input remains smooth, zoom is centred correctly, reset fits the full map and no pin moves relative to the artwork.

MAP-06 — Warm cache

Priority: High.

1. Complete MAP-01.
2. Close and reopen F1 ten times.
3. Reconnect and reopen it.
4. Inspect requests and load timing.

Expected: the versioned service worker serves the optimized map, scripts, styles and pin images from cityrp-f1-map-20260730-7. The page shell may revalidate. No stale earlier-version asset is used.

MAP-07 — Cache update

Priority: High.

1. With the previous beta cache present, deploy the candidate asset version.
2. Reopen F1.
3. Confirm the new cache activates and the earlier version is deleted.

Expected: the candidate map and JavaScript load without requiring players to clear browser data manually.

MAP-08 — Runtime locations and Nearest

Priority: Critical.

1. Confirm saved and registered locations appear.
2. Move or recreate a dynamic Nearest entity.
3. Wait for the next map refresh.
4. Select the Nearest row and its action button.

Expected: Nearest entries remain list-only, resolve the current closest entity and never draw a map pin. Ordinary locations refresh without duplicating rows.

MAP-09 — Player direction

Priority: High.

1. Rotate the camera and model together on foot.
2. Drive straight while free-looking left, right and backwards.
3. Repeat as a passenger.

Expected: on foot the arrow follows camera/model facing. While seated it follows the rendered player/vehicle direction and is unaffected by free-look. The 32-pixel base player arrow remains clearly visible without obscuring nearby pins.

MAP-10 — M key toggle

Priority: High.

1. Press M with F1 closed.
2. Press M again after the Map tab is active.
3. Hold M down for at least two seconds after opening and after closing.
4. Open another F1 tab and press M.
5. Focus the hosted map before repeating the close action.

Expected: the first press opens Map, the second closes F1 even after DHTML focus, and pressing M from a different F1 tab switches to Map. Holding the key causes exactly one state change, and the M close releases mouse focus, dropdowns and panels identically to the X button.

3. Minimap and compass

HUD-01 — Context-menu settings

Priority: Critical.

1. Hold C and open HUD Options → Toggle Minimap.
2. Select Default Size, Small Size and Toggle Compass.
3. Close and reopen the menu after each choice.
4. Reconnect.

Expected: child options draw and remain clickable; checkmarks reflect current archived values; settings persist; no old position choices or minimap chat commands exist.

HUD-02 — Minimap controls

Priority: High.

1. Test −, reset and + while C is held.
2. Repeat in both minimap sizes and at every HUD scale.
3. Release C and click the same screen positions.

Expected: the compact 22-pixel-scaled controls do not obscure the player arrow; only C mode accepts clicks; zoom remains within configured limits; reset returns to 1.0.

HUD-03 — Minimap presentation

Priority: High.

1. Walk and drive across map and artwork boundaries.
2. Inspect the frame, corners and area beyond the PNG.

Expected: the border matches other HUD elements, the outer map colour is #1a1a1a, no north pointer is present, and no redundant destination name or distance is drawn below the minimap.

HUD-04 — Heading rules

Priority: Critical.

1. On foot, rotate the view through 360 degrees.
2. Enter a driver seat and drive in all cardinal directions.
3. Free-look through 360 degrees while the vehicle keeps its heading.
4. Repeat as a passenger.

Expected: on-foot minimap and compass follow camera yaw; seated navigation follows model/vehicle-aligned render yaw; no 90-degree offset or skew occurs.

HUD-05 — Compact compass

Priority: High.

1. Enable small minimap mode.
2. Rotate slowly through 360 degrees.
3. Set and clear a waypoint.

Expected: primary cardinals and numeric subheadings form an even 30-degree sequence; labels do not collide; no waypoint icon appears on the compass.

HUD-06 — Through-wall marker

Priority: Medium.

1. Set a waypoint behind a building and outside the minimap crop.
2. Approach and pass it.

Expected: the separate world marker and edge-clamped minimap destination remain usable; removing the compass icon does not remove destination guidance.

4. Road navigation

NAV-01 — Graph diagnostics

Priority: Critical.

1. Run !waypointdebug status.
2. Run !waypointdebug roads.
3. Run !waypointdebug off.

Expected: status prints the packaged JSON path, graph state and active route; roads mode overlays recognized nodes; off removes all debug drawing.

NAV-02 — On-road route

Priority: Critical.

1. Set routes between at least six distant location pairs.
2. Include inner city, outer city, industrial, docks and mountain approaches.
3. Drive each route.

Expected: #0D47A1 follows recognized roads, corners and caps are rounded, the stroke is clearly visible at the approved thickness, and the route advances without reversing to completed points.

NAV-03 — Off-road connection

Priority: Critical.

1. Start off-road and set an on-road destination.
2. Start on-road and set an off-road destination.
3. Test both endpoints off-road.

Expected: only the connection between the endpoint and nearest recognized road uses #546E7A; the road section stays #0D47A1.

NAV-04 — Reroute and arrival

Priority: Critical.

1. Leave the shown route by more than three 256-unit cells.
2. Rejoin at a later road.
3. Enter the destination radius.

Expected: the server recalculates without rapid oscillation, sends the updated route once, and clears navigation on arrival.

NAV-05 — Missing or invalid road data

Priority: High.

1. On a development copy, start with missing and malformed road JSON.
2. Set a waypoint.

Expected: startup reports the graph failure without crashing; navigation falls back to a direct off-road segment; F1 and minimap remain functional.

5. Waypoint commands and access

CMD-01 — Public commands

Priority: High.

Test:

/waypoint <location>
/waypoint goto <location>
/waypoint clear
/waypoint end
/waypoint stop
/waypoints list

Expected: named navigation and clearing work for a normal player. Staff action words are not interpreted by /waypoint. /waypoints list prints the server-authoritative public destination names, categories and matching commands to the client console without opening Derma.

CMD-02 — Guide bridge

Priority: High.

1. Open the New Player Guide.
2. Use its map/waypoint action.

Expected: it opens the F1 Map tab through cityrp_open_map; it does not send /waypoints to chat.

CMD-03 — Command discovery

Priority: High.

1. Open F1 Commands as an RP Assistant.
2. Locate all waypoint administration commands.
3. Repeat as a normal player.

Expected: assistants see each complete example and description below; non-staff do not see the Assistant category.

Command example	Expected purpose
!waypointset "Industrial Road" visible	Save the aimed position
!waypointcategory add "Fuel Stations" red diamond	Add or edit a category
!waypointsetcategory "Inner City BP" "Fuel Stations"	Move a location
!waypointhide "Staff Garage"	Hide a pin
!waypointshow "Staff Garage"	Restore a pin
!waypointdelete "Old Location"	Delete a saved location
!waypointplayer Vadar "Inner City BP"	Assign another player
!waypointexport	Print saved JSON
!waypointdebug roads	Show routing diagnostics

CMD-04 — Access enforcement

Priority: Critical.

1. Attempt every !waypoint... administration command as a normal player.
2. Repeat as RP Assistant and higher staff.
3. Check command logs.

Expected: normal players are rejected before callbacks run; assistants and higher staff succeed; every attempt is logged by the normal acommands path.

CMD-05 — Mutation and persistence

Priority: Critical.

1. Create a category.
2. Save a visible and hidden point.
3. Move, hide, show and delete points.
4. Export the JSON.
5. Restart the server.

Expected: validation messages use the new command syntax; changes persist; hidden points remain directly addressable; the F1 list reflects each mutation after refresh.

CMD-06 — Staff assignment

Priority: High.

1. Assign a named location to another player.
2. Assign the aimed position.
3. Clear it.
4. Test invalid and ambiguous player names.

Expected: the intended player alone receives the waypoint; errors are clear; legacy place coordinates are available only through staff assignment.

CMD-07 — Boosting administration

Priority: Critical.

1. Confirm /boosting is no longer registered.
2. Locate !boosting admin status with its example and description in F1 Commands.
3. Exercise point, spawn, admin and debug actions as an administrator.
4. Repeat as a normal player and test debug as a non-superadmin.
5. Add delivery and spawn points, restart, then run both reload actions.

Expected: the acommand access path enforces administrator and debug permissions; usage messages use !boosting; delivery points persist in cityrp/plugins/carboosting/<map>.txt; spawn anchors persist in cityrp/plugins/carboosting/spawns_<map>.txt.

6. Lockpick, hotwire and engine hint

VEH-01 — Lockpick HUD clearance

Priority: High.

1. Lockpick at all required resolutions and HUD scales.
2. Trigger low durability and bending warnings.
3. Move the pick without pressure, then apply and release tension at incorrect and correct angles.

Expected: condition, warning and instructions stay below the barrel and do not overlap the minimap or integrated compass. Guidance arrows are hidden without pressure, appear only while tension is applied and disappear when released.

VEH-02 — Hotwire presentation

Priority: High.

1. Start the hotwire task.
2. Drag correct and incorrect wires.
3. Cancel, retry and complete it.

Expected: the panel matches Car Boosting styling; NO TIME LIMIT is absent; buttons show correct enabled, hover and disabled states; cancelling sends once.

VEH-03 — Hotwire authority

Priority: Critical.

1. Submit incomplete, incorrect, malformed and replayed answers.
2. Move away, leave the vehicle and disconnect mid-task.

Expected: the server rejects invalid answers, interrupted sessions close, and the client cannot start an engine by forging only the completion message.

VEH-04 — Engine guidance

Priority: Medium.

1. Look at an engine-off vehicle with hints enabled.
2. Enter its driver seat while the engine remains off.
3. Start the engine and re-enter it.
4. Enter as a passenger.
5. Disable hints.

Expected: the hold-to-start instruction appears only while the engine is off and hints are enabled; entering the driver seat with an engine-off vehicle shows the HUD hint instead of a chat reminder; running vehicles and passengers receive no reminder.

7. Car Boosting contracts

BST-01 — Offer and class gating

Priority: Critical.

1. Test MESKA levels 1 through 5.
2. Refresh offers and attempt forged acceptance above the player's level.

Expected: D, C, B, A and S unlock at levels 1, 2, 3, 4 and 5; the server rejects unauthorized class acceptance regardless of tablet UI.

BST-02 — Target lifecycle

Priority: Critical.

1. Accept one player-owned and one generated target.
2. Inspect engine, lock, ownership and reservation state.
3. Fail and complete each type.

Expected: targets start with engines off; persistent garage ownership is not transferred or deleted; cleanup releases reservations and generated entities.

BST-03 — Required actions and timing

Priority: Critical.

Test every class and contract archetype.

Expected:

• the initial search window is ten minutes;
• D/C use the baseline window;
• B adds Fake Plate and one tracker allowance;
• A/S add Fake Plate and two tracker allowances;
• the archetype multiplier applies after allowances; and
• timers transition once and cannot be bypassed by re-entry or reconnect.

BST-04 — LimeTrack and police reports

Priority: High.

1. Drive with an active tracker at low and high Heat.
2. Complete the final challenge with and without a valid driver.

Expected: standard 911 formatting uses LimeTrack™:; reporting frequency follows Heat; the final location is sent through the correct fallback actor.

BST-05 — Crew contribution and payout

Priority: Critical.

1. Invite three tablet carriers.
2. Test distant, nearby, accepted and declined members.
3. Complete A/S with too few and sufficient members.
4. Exercise every contribution source.

Expected: only eligible nearby accepted members join; contribution is recorded; cash, parts and XP split correctly; crew_boosts increments only for qualifying successful crews.

BST-05A — Crew controls and realtime roster

Priority: Critical.

1. Open the Crew page as an owner with an ungrouped tablet user online.
2. Confirm the full Invite button is visible and invite that user.
3. Accept the invitation while both Crew pages remain open.
4. Leave from the member account without reopening either tablet.
5. Rejoin, then use the owner's Kick button and confirmation.
6. Disconnect a member while the owner's Crew page remains open.
7. Repeat at every required resolution and HUD scale.

Expected: invite and owner controls retain their full width and height; accepted, left, kicked and disconnected members update on every open Crew page without reopening or stealing focus; kicked members receive a notification; only the owner sees Kick and Make Owner; membership changes remain locked during an active contract.

BST-06 — Failure and cleanup

Priority: Critical.

Trigger acquisition timeout, delivery timeout, destruction, abandonment, disconnect and staff termination.

Expected: Heat, metrics, reservations, waypoint, tracker, plate and target state settle exactly once with no orphan hooks or timers.

BST-07 — Target signal

Priority: High.

1. Stand at the target, then at 256, 5,000, 9,999 and more than 10,000 units.
2. Enter the target vehicle and compare the server state with the HUD.
3. Repeat with live-target client adjustment active.
4. Repeat the full signal-strength approach in first and third person.

Expected: the target and any position within the full-strength radius show exactly 100%; signal falls smoothly to zero across the doubled 10,000-unit range; server and client calculations agree. Every signal beep remains audible in both camera modes and its interval accelerates as strength increases.

8. MESKA

MSK-01 — Parent registry ordering

Priority: Critical.

1. Remove Boosting rows only from a disposable beta test identity/schema.
2. Start the server.
3. Inspect meska_skills, then meska_metrics.

Expected: meska_skills.name = boosting exists before the metrics upsert; no foreign-key failure occurs.

MSK-02 — Skills page

Priority: High.

1. Open Skills on new and existing players.
2. Inspect category, level, XP and achievements.

Expected: Boosting Skill is visible as its own category, all configured Boosting achievements are present, and no Boosting guides are shown. Guidance remains available only through the Boosting tablet.

MSK-03 — D achievement gate

Priority: Critical.

1. Use a new player at Boosting level 1 with 0 XP.
2. Run an achievement scan.
3. Complete one successful job and earn XP.
4. Run or wait for the next scan.

Expected: D Is for Driveaway is not awarded at 0 XP and is awarded once boosting_exp >= 1.

MSK-04 — Metric requirements

Priority: Critical.

1. Test a player whose MESKA cache lacks skills.boosting.
2. Test each Boosting metric achievement threshold.

Expected: a missing skill is treated as unmet without indexing nil; each achievement awards once at its exact threshold.

MSK-05 — Persistence

Priority: Critical.

1. Record Boosting metrics, XP, level and achievements.
2. Reconnect.
3. Restart the server and reconnect again.

Expected: database and in-memory values agree; no duplicate achievements or XP are granted.

MSK-06 — Reset procedure control

Priority: High.

Confirm no unrestricted MESKA reset command exists. If QA needs a reset, use a reviewed, SteamID-scoped beta database procedure with a backup and reconnect. Never test it against live data.

9. Performance, networking and security

PERF-01 — Client frame cost

Priority: High.

Profile:

• minimap alone;
• minimap with a long route;
• compact compass;
• F1 open with all pins; and
• staff road overlay.

Expected: no sustained frame-time spike or allocation growth; closing F1 releases its hook and panel; disabling the minimap removes its draw work. Record the same stationary, walking, driving and routed samples with the minimap disabled and enabled. The enabled result must not cause a material sustained FPS collapse, and the optimized scissor/route path must not introduce flicker, clipping leaks or broken route joins.

PERF-02 — Server route cost

Priority: High.

1. Profile simultaneous routes for the expected peak player count.
2. Force off-route recalculation.
3. Soak for two hours.

Expected: A-star work remains bounded, recalculation occurs at most on its two-second check and only when route state requires it, and server tick remains within the existing budget.

PERF-03 — Network cadence

Priority: High.

Expected:

• F1 player location sync is no faster than every 0.15 seconds;
• navigation state is sent to DHTML only after a state change;
• map data refresh is no faster than every 30 seconds per open panel;
• server map requests remain rate-limited;
• route points never exceed the 255-point network limit; and
• debug nodes never exceed 4,095.

SEC-01 — DHTML boundary

Priority: Critical.

Confirm the F1 DHTML has general Lua disabled and exposes only the explicit setWaypoint and endNavigation bridge functions. Runtime coordinates remain in-memory and are not uploaded to the web service.

SEC-02 — Net-message validation

Priority: Critical.

Send oversized, unknown and repeated destination identifiers, rapid map requests, repeated end requests and invalid hotwire payloads from a development client.

Expected: the server bounds, sanitizes, throttles or safely rejects each input; no arbitrary coordinate or staff mutation path is exposed.

10. Regression suite

Priority: Critical unless stated otherwise.

Confirm:

• normal F1 tabs still open and lay out correctly;
• F1 Commands filters commands by rank and shows player commands;
• the New Player Guide loads with and without Waypoints;
• vehicle ownership, keys, locks, /engine and ordinary hotwiring still work;
• non-Boosting lockpicks retain durability and cancellation behavior;
• HUD, stats, daily bonus and custom bonus context-menu controls still work;
• map material retry and cache validation handle a failed download;
• death and disconnect clear active waypoint state;
• other MESKA skills, metrics and achievements still award normally;
• normal 911 messages remain unchanged;
• non-Boosting vehicle spawn and cleanup behavior is unchanged; and
• Car Boosting disabled state prevents new contracts without corrupting active or saved data.

11. Rollout and rollback

Rollout order

1. Freeze and record both candidate commits.
2. Back up affected MESKA tables and Car Boosting/Waypoint data files.
3. Publish only the service-map/beta candidate.
4. Verify the public beta F1 URL and cache update.
5. Deploy the CityRP development candidate to one test server.
6. Run DEP, MAP, HUD, NAV, CMD, VEH and MSK smoke cases.
7. Run the complete Boosting class matrix.
8. Complete the two-hour soak and compare logs/performance.
9. Obtain QA, development and operations sign-off.
10. Schedule live promotion as a separate reviewed change.

Rollback triggers

Rollback immediately for:

• MESKA foreign-key or player-load errors;
• persistent Lua errors;
• route calculation causing server hitching;
• F1 blank map or unusable categories;
• unauthorized waypoint mutations;
• Boosting target ownership loss;
• duplicated payout, XP or achievements; or
• contract cleanup leaving reserved vehicles.

Rollback procedure

1. Stop new Boosting contracts.
2. Preserve logs and affected player identifiers.
3. Revert the game candidate to the recorded previous commit.
4. Revert the beta web assets/cache version if the fault is web-only.
5. Restore database rows only when the defect changed persistent data and the operations owner approves the scoped restore.
6. Restart, run startup smoke checks and confirm active sessions are clean.
7. Document cause, impact and retest requirements before another candidate.

Sign-off

Role	Name	Result	Date	Evidence link
QA
Development
Server operations
Product owner