diff --git a/work_note2 b/work_note2 new file mode 100644 index 0000000..ab93836 --- /dev/null +++ b/work_note2 @@ -0,0 +1,48 @@ +--- + 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 + +