49 lines
2.9 KiB
Plaintext
49 lines
2.9 KiB
Plaintext
---
|
||
Still Needs Attention
|
||
|
||
1. float altitude is now listed twice in target_data_structure (lines 130 and 136).
|
||
float altitude; // in meters ← line 130, was originally "float height"
|
||
...
|
||
float altitude; // meters, but 0 for boats ← line 136
|
||
It looks like the original float height (structural height of the vessel) got accidentally renamed to altitude,
|
||
creating a duplicate. The structural height of the vessel is a distinct concept from flight altitude. float
|
||
height should be restored at line 130, or the duplicate removed if structural height is intentionally dropped
|
||
from the structure.
|
||
|
||
2. getMaterialProfile parameter still mismatches the switch.
|
||
The function signature is getMaterialProfile(int aisTypeCode) but the switch operates on vessel_type. In actual
|
||
C++ code, vessel_type would be out of scope inside the function — the parameter would need to be named
|
||
vessel_type, or the switch would need to use aisTypeCode. Minor, but would cause a compile error.
|
||
|
||
3. Missing semicolons on the last two SSBO struct fields (lines 154–155).
|
||
int32_t police_boat // no semicolon
|
||
int type // no semicolon
|
||
Would be compile errors in real code.
|
||
|
||
4. binary may_need_update in the database schema (line 1001) is still not a proper type.
|
||
int32_t police_boat was correctly fixed, but may_need_update still uses binary. In PostgreSQL this should be
|
||
BOOLEAN or SMALLINT. Should be consistent with police_boat.
|
||
|
||
5. timestamp elapsed_seconds — the name and type contradict each other.
|
||
A PostgreSQL TIMESTAMP stores a calendar date+time (e.g., 2026-05-28 14:30:00), not a count of elapsed seconds.
|
||
If the intent is seconds-since-epoch, the column type should be BIGINT (and the name elapsed_seconds makes
|
||
sense). If the intent is an actual timestamp, use TIMESTAMP and name it last_seen or similar. The current
|
||
combination is confusing.
|
||
|
||
---
|
||
Minor
|
||
|
||
- Line 1185: typo "shouse" → "should"
|
||
- The unresolved architectural question from before (does traffic_cop filter for the currently active scope
|
||
only, or does it maintain separate lists per radar?) is still implicit. This may become clear once the simulator
|
||
section is written, so it may not need addressing now.
|
||
|
||
✻ Crunched for 59s
|
||
|
||
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||
❯
|
||
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
|
||
? for shortcuts · ← for agents
|
||
|
||
|