BYDMate Waze 3.16.1-dev.3

BYDMate Waze 3.16.1-dev.3 (development pre-release)

The lane strip is cropped from the rectangles Waze's own accessibility tree gives, instead of
being re-derived from the pixels, and Waze's reports list becomes the car's camera source.

Added

• Cameras from Waze's reports list. navListReportsList is plain text — a type row beside a
  distance row — and it is the one place on this build where a camera is a word. The nearest
  camera ahead is sent to the panel as sendCameraGuidanceInfo(1, metres, 1), the only camera
  call this cluster has been seen to draw (it is what puts the speed-limit roundel there), and its
  disappearance as the donor's clear, type 0 at -1 m. A camera nobody reports again for ten
  seconds leaves the glass on its own. Police and hazard rows are read and logged but draw
  nothing: they have no sign of their own yet. The words live in the language packs
  (assets/navi/phrases/<lang>.json, new "reports" section), never in code. Every change is a
  REPORT line in the trip log, and every panel write a PANEL line.
• Lane rectangles in the trip log. The LANES lines now carry
  display=… container=l,t,r,b cells=n [l,t,r,b …], so a drive finally says which widget the
  classifier looked at. Cells whose signature matched nothing carry their 225 shape bits
  (grid#i=…, at most eight per line), which is what the lane table has to be built from.
• Bounds on node discovery. Every TREE new id=… line ends with bounds=l,t,r,b.

Changed

• Lane crops come from the tree. Where laneGuidanceView has leaf children — 3, 5, 7 or 8 of
  them on the 2026-09-15 drive — their rectangles are the lane crops directly. The donor's column
  segmentation kept finding fewer cells than the tree has (3 against 5, 1 against 5) and is now
  only the fallback for a strip drawn as a single view. Each cell is classified at the same two
  thresholds as before, and a lane counts as on-route when its brightness reaches 0.9 of the
  brightest cell's, which is the donor's own rule.