Changelog: SQVL-MESH

A concise release history of what changed in the project.

  1. Team rooms passed complete testing on two different Android phones, including setup, member management, restart, lost connection, and recovery. The project now has 483 passing automated checks; the latest installable Android build remains 0.12.10.

  2. Prepared a stable candidate for the final team-room tests, including interrupted setup, reconnects, and switching between foreground and background. No new Android build was published until those physical checks were complete.

  3. Designed new GPS controls that would filter small position jumps on the phone while sending only the latest useful update over the Internet. This release defined the behavior but did not change the application.

  4. Reset the test environment and repeated the complete room scenario on Pixel and Sony phones. Clean setup, room separation, reciprocal map markers, reconnects, and session recovery all worked as expected.

  5. Added a temporary Android workaround for networks that could not find the test server address. It restored access on the affected Sony phone, but remains a narrowly limited fallback rather than a permanent part of the system.

  6. Updated the Android app identity and made form labels remain visible while typing; passwords stay hidden and are not retained. The result was checked across Pixel and Sony phones, both orientations, themes, and keyboard states.

  7. Defined the controlled rollout for a small Android test group, including the remaining reliability, network, cleanup, and distribution checks. This was a release plan, not a visible application update.

  8. The Public room gained a complete participant list with names, roles, life status, online state, and GPS freshness. It was verified on Pixel and Sony phones without changing how positions are stored or displayed on the map.

  9. Added a protected read-only Admin view for observing permitted rooms without appearing as a participant. A three-device test confirmed that the observer could see room activity but sent no participant data back.

  10. Creators of private rooms can now rename a room, change its password, remove members, and permanently delete it after confirmation. Ordinary members do not receive these controls, and the complete flow was physically tested.

  11. Android users can create password-protected teams, join them, recover membership after returning, view the authorized roster, and leave deliberately. The release passed 414 automated checks across the app, server, and shared message rules.

  12. Added the first Android team lobby with a clear state for users outside a room and the ability to join or leave the Public room. Membership and room data recover after reconnecting, while data from other rooms stays isolated.

  13. Built an isolated server foundation for team rooms, with room separation, revocable access, recovery rules, and persistent storage. It was tested separately so the existing public service and mobile application remained unchanged.

  14. Defined and tested the message and authorization rules required for team rooms without switching the running product to them. This prepared mobile and server development while keeping the existing application behavior intact.

  15. Designed how team rooms, passwords, recovery, storage, and capacity limits should work before implementation began. The plan covered 37 usage scenarios and loads of up to 512 connected clients; no visible feature changed.

  16. Completed more than a week of Android and iOS field testing for GPS freshness, direction, speed, distance, and arrival estimates. The Internet-based product was accepted for continued development; mesh communication was still not integrated.

  17. Fixed screen orientation and popup spacing after returning to the application on Android and iOS. The map and GPS state now remain intact while the interface adapts correctly to the current screen.

  18. Unsupported or damaged KMZ map files now produce clear, privacy-safe explanations instead of vague failures. The tactical-symbol size control was also stabilized so it no longer fights with page scrolling.

  19. Made diagnostics easier to read, reduced GPS status to a compact control, and displayed map direction as a fixed three-digit value. The underlying GPS data and recovery behavior did not change.

  20. Testing showed that the available iPhone did not provide reliable compass readings. iOS compass support was left unaccepted until it could be checked on a known-good device; the application itself did not change.

  21. Added a true-heading compass to the Android map, including direction, azimuth, and a visual bearing cone. Android passed physical and automated testing; the unresolved iPhone sensor issue remained separate.

  22. Defined the first team-room model: a local mode without a room, one Public room, password-protected private rooms, and a protected read-only Admin view. This release described future behavior and did not change the running application.

  23. The map now remembers its centre, zoom, rotation, and tilt between sessions. Loading saved map layers no longer moves the camera away from the view chosen by the user.

  24. Participant and self-position markers now always stay above imported map layers, so important live information cannot be hidden by an overlay. The ordering works consistently on Android and iOS.

  25. Prepared the next two map improvements: a local compass and memory for the user's chosen camera view. This release only defined the work; the controls were not yet available in the application.

  26. Users can import up to 24 KMZ map layers on Android and iOS, change their order and visibility, jump to the required area, and delete layers they no longer need. The complete workflow passed automated testing.

  27. Added reliable local storage for imported map layers. The application remembers their names, order, visibility, size, and state after restart, and can recover safely from damaged or interrupted imports.

  28. Built the shared KMZ import process for Android and iOS. Files are checked and processed entirely on the device, with progress, cancellation, clear errors, and automatic cleanup when an import fails.

  29. Proved that the same locally stored KMZ map can render correctly on Android and iOS. The test covered one common overlay format; broader KMZ compatibility was still outside the accepted scope.

  30. Defined the Layers screen and the rules for importing, ordering, hiding, and deleting up to 24 local KMZ maps. This was architecture and interaction planning; no visible feature was added yet.

  31. Improved participant markers and added a preview control for tactical-symbol size. Wounded, dead, and stale-data timers update locally without generating extra network traffic; 149 automated checks passed.

  32. Replaced abbreviated role codes with clear, stable role identifiers for rifleman, grenadier, machine gunner, marksman, and medic. Existing profile recovery and mixed application versions continued to work.

  33. Simplified how participant roles and tactical symbols are represented so one can change without corrupting the other. This internal update prepared more reliable profile synchronization without changing the visible product.

  34. Participant roles now appear as tactical symbols both in the profile and on the shared map. The same information is reused locally, so the clearer presentation does not make network messages larger; physical testing passed.

  35. Created the first tactical-symbol engine for the five participant roles, friendly affiliation, and life status. It produced consistent symbols and passed 139 automated checks plus an Android visual test.

  36. Expanded participant status from alive or dead to alive, wounded, and dead. The application also records when the status changed and shows how long the casualty state has lasted.

  37. Replaced the large GPS warning card with a compact status indicator and a relevant recovery action. The map stays easier to read while all existing GPS behavior remains available.

  38. Applied compatible maintenance updates and fixed the System Status layout after rotating the device. All 129 automated checks passed, with no change to user data or communication behavior.

  39. Accepted edge-to-edge maps that still keep controls clear of notches and system areas on Android and iOS. The status panel also adapts to different screens and shows diagnostic time in the device's local timezone.

  40. The map centre now shows an MGRS grid coordinate calculated offline, and the whole coordinate can be copied with one tap. The feature works without sending the viewed location to a server.

  41. Updated the delivery plan to reflect the accepted Internet version and split new tactical requirements into smaller, testable steps. This release changed planning only, not the application.

  42. Reorganized the internal GPS controller into smaller parts while preserving exactly the same behavior. The change passed automated tests and physical review on three devices, making future GPS work safer.

  43. Reorganized the full-screen map interface into smaller components without changing how it looks or behaves. Automated and physical Android/iOS checks confirmed that GPS, participants, storage, and communication still worked.

  44. Moved distance, direction, speed, and arrival-time information beside the centre reticle so it remains readable on both Android and iOS. Navigation calculations themselves did not change.

  45. Updated outdoor, tablet, endurance, and data-frequency test plans around the accepted position modes: Off, While open, and Background. This was planning only and did not change the application.

  46. Replaced separate location switches with one clear selector: Off, While open, or Background. This removes conflicting combinations and keeps all permission and recovery logic in one place.

  47. Prevented rapid repeated taps on Android background location controls from starting conflicting GPS operations. The control now waits for the current start or stop action to finish before accepting another request.

  48. Fixed an Android issue where returning from the recent-apps screen could interrupt automatic map following. The correction stayed inside the map behavior and passed the complete mobile test suite.

  49. Player Profile now displays correctly in landscape orientation on iPhone. The issue was isolated to the popup presentation and fixed without changing profile data or communication.

  50. Turned 13 new operational goals into a dependency-aware delivery plan and kept unresolved choices visibly open. This release changed requirements and priorities, not the application.

  51. Physically accepted iPhone background positioning, receive-only mode, network recovery, and recovery after force-closing the app while exchanging data with an Android phone. All 86 automated checks also passed.

  52. Built and physically accepted the first standalone iPhone application from the same source as Android. It launches without a development computer and supports the foreground map and GPS flow.

  53. Completed the local iOS development and signing setup, then launched the shared application on both an iPhone simulator and a physical iPhone. A standalone user build was still the next step.

  54. Applied seven compatible maintenance updates to the mobile application without changing its behavior. All 80 automated checks passed and the development toolchain reported no outdated required packages.

  55. Both physical LoRa mesh devices arrived, charged, and powered on, removing the hardware delivery blocker. They were ready for the first radio test but were not yet connected to the application.

  56. Field tests confirmed realistic walking and driving speed, distance, direction, and arrival estimates: walking ETA was within about 30 seconds, and car speed differed by roughly 2 km/h. iOS work began, but no iPhone-ready version was claimed yet.

  57. Participant profiles were accepted between users in different locations, including stable identity, editable names, five roles, life status, reconnects, and cached recovery. Compact mesh recovery and shared identity trust remained future work.

  58. Moved the relay server from a home computer to a persistent VPS with health checks, protected access, and quick rollback to the previous version. All 79 automated tests passed without changing the mobile communication flow.

  59. Prepared a safer restructuring of the map and GPS logic so future changes could be made independently and with less risk of regressions. There were no visible user-facing changes in this release.

  60. Combined location settings into one control and added reliable background tracking, receive-only operation, and recovery from permission or task failures. Physical Android testing confirmed that positions continue to arrive with the screen locked.

  61. A clean Android reinstall reproduced an old participant marker that should no longer have appeared, proving the problem was not limited to the phone's local data. The defect was documented for further server-cache investigation rather than presented as fixed.

  62. Added persistent participant profiles with editable names, five roles, and alive or dead status. Profiles synchronize separately from GPS, survive reconnects, and were accepted in a physical two-phone test.

  63. Confirmed on two Android phones that the application still exchanges positions after its communication system was prepared for multiple transport types. Internet behavior stayed unchanged while the future mesh connection gained a clean integration point.

  64. Separated GPS, map, participant, storage, diagnostics, and communication responsibilities so a future mesh connection could be added without rebuilding the whole application. Automated checks passed; physical testing followed in the next release.

  65. Field testing on two Android phones confirmed the fix for stationary users being incorrectly marked as stale. Current GPS data and remote markers now remain fresh even when a person is not moving.

  66. Added and accepted the main map controls: zoom, automatic follow, manual follow cancellation, left- or right-handed layout, centre reticle, live coordinates, and a collapsible status panel. The physical build was reviewed on a phone and tablet.

  67. Added left- or right-handed placement to the map-control specification so the complete button group can sit on either edge. This release changed the design only; the application was not updated yet.

  68. Defined automatic map following: tapping location starts continuous follow, while deliberate map movement stops it and changes the control state. The interaction was specified but not yet added to the Android build.

  69. Planned the first quality-of-life controls for phone and tablet maps: zoom, self-position follow, a status toggle, and a centre reticle. Creating and sharing map objects remained outside this release.

  70. Compared options for adding offline maps and clarified the difference between geographic data and the software that displays it. No provider was selected until licensing, storage, updates, platform support, cost, and dependency risks could be verified.

  71. Physical testing found that a stationary phone could be marked as stale even while receiving valid GPS data. The cause and correction were defined, but the fix was not yet included in the application.

  72. Two physical Android phones successfully exchanged live positions and profiles through the public relay, including reconnects and background updates. The server could restart automatically, but still ran on a home computer.

  73. Built a standalone Android test application that contained everything needed to connect to the public relay without a development computer. The package was verified, while mobile-data and two-phone testing remained the next step.

  74. Made the home-hosted relay reachable through a protected public address without opening the home router. External connection and safe health reporting worked; physical phone acceptance was still pending.

  75. Prepared the secure tunnel needed to expose the relay while keeping the server isolated from the home network. Account setup and public connection testing were still incomplete, and no credentials entered the repository.

  76. Set up the relay as a restricted service that starts and restarts reliably while remaining inaccessible from the local home network. All checks passed before exposing it through a public tunnel.

  77. Added optional protected access to the relay server. The access token stays in server settings instead of public links or project files, preparing safer external testing without changing message content.

  78. Defined a limited pilot for running the relay on a home computer through a managed secure tunnel, without opening router ports. This was a deployment plan; the server was not publicly reachable yet.

  79. Defined how one Android build could switch between development and hosted servers and let each participant set a callsign. These requirements were recorded for later implementation; neither feature was available yet.

  80. Built and inspected the first standalone Android application for 64-bit devices. It included the map and current Internet foundation, while background GPS, permanent hosting, and mesh communication remained outside the accepted build.

  81. The responsive phone and tablet status interface passed owner review and became the accepted baseline. No new behavior was added beyond approving the already tested candidate.

  82. Added separate status layouts for phones and tablets plus diagnostics that can be shared without exposing coordinates, identities, tokens, or server details. The implementation passed 20 automated checks; owner acceptance followed in the next release.

  83. Proved the first complete Internet position exchange between two application clients. The server validates and forwards updates, reconnecting clients receive the latest useful state, and accepted data remains available after an app restart.

  84. Added a local database for permanent device identity, received-message history, and the latest participant state. Invalid, expired, duplicate, or older updates are rejected, and useful state survives an application restart.

  85. Defined one shared, automatically checked message format for participant identity, callsigns, groups, positions, profiles, timestamps, and expiry. The mobile application and server now reject malformed data in the same way.

  86. Added foreground phone GPS, permission handling, accuracy information, and the first self-position marker on the map. Background tracking and other participants were not part of this version.

  87. Added the first full-screen mobile map and verified that it rendered correctly on Android. GPS, networking, and offline maps were not connected yet.

  88. Created the first shared project structure containing the mobile application, relay server, and common message rules. The Android client could run, while iPhone, Bluetooth, and physical-device behavior were still unverified.

  89. Published the first tracked project baseline to the remote repository while keeping generated files, credentials, and private operational data out of it. This release changed project delivery, not product behavior.

  90. Prepared and verified the local Android development environment, including the required tools and a 64-bit emulator. No application or physical-device behavior was claimed at this stage.

  91. Connected and verified the remote repository while keeping private operational records local. The project was ready for its first explicit publication, but no remote development history existed yet.

  92. Established the project foundation: what the system should do, which inputs can be trusted, and how decisions and tests should be recorded. The application did not exist yet.