Add basic movement state to transform packets

Add optional movement-state fields (isMoving, isSprinting, isSneaking, isJumping, weaponDrawn, movementSpeed) to transform packets and wire them end-to-end. Plugin changes: extend F4TNetworking API and RemotePlayerState, derive movement speed/jump state on the game-thread, validate values, include fields when formatting transform JSON, and add throttled remote movement-state logging. main.cpp adds sampling, speed/vertical calculations, jump hold logic, and change-detection to avoid extra sends. Networking parsing (F4TNetworking.cpp) reads optional booleans/floats safely, preserves backwards compatibility, and clears movement-state logs on disconnect. Proxy controller includes a TODO note for future animation use. Server and docs: update protocol and packet docs, dev-log, server README, and fake_client.py to parse/display optional fields safely. Also add several .cursor rule files for coding, documentation, protocol, project overview, and testing guidance. This milestone prepares the data model for later animation/behavior work while keeping existing relay behavior unchanged.

.cursor/rules/coding-standards.mdc

@@ -0,0 +1,33 @@
+---
+description: C++ plugin and Python server coding standards
+alwaysApply: true
+---
+
+# Coding Standards
+
+For C++ plugin work:
+- Prioritise stability and safety over cleverness.
+- Avoid unsafe game-thread access.
+- Interact with Fallout 4 runtime objects on the game thread unless clearly safe otherwise.
+- Use defensive null checks for pointers, actors, cells, worldspaces, forms, and lookup results.
+- Do not crash the game if a pointer, actor, cell, worldspace, or form lookup fails.
+- Use throttled logging for repeated runtime events.
+- Keep logs useful for debugging, but do not spam the log every frame.
+- Keep networking code separated from game-world manipulation where possible.
+- Preserve existing behaviour unless the requested change requires modifying it.
+- Do not make large architecture rewrites unless explicitly requested.
+- Prefer small, testable milestones.
+
+For Python server work:
+- Keep the server simple and readable.
+- Preserve unknown JSON fields where possible so the protocol can evolve without breaking older code.
+- Treat malformed packets as client input errors, not server-fatal errors.
+- Do not crash the server because of one bad client message.
+- Preserve backwards compatibility unless specifically requested.
+- Keep `server/fake_client.py` useful for testing protocol changes.
+
+General implementation guidance:
+- Prefer clear naming over overly abstract systems.
+- Add TODO comments only where they are genuinely useful.
+- Do not remove useful debugging logs unless they are too spammy.
+- Do not remove fallback behaviour or safe defaults.

.cursor/rules/documentation-rules.mdc

@@ -0,0 +1,54 @@
+---
+description: Documentation and development log update rules
+alwaysApply: true
+---
+
+# Documentation Rules
+
+After every meaningful code change, update the relevant documentation. Do not let code and documentation drift apart.
+
+Always consider whether these files need updates:
+- `docs/dev-log.md`
+- `docs/protocol.md`
+- `docs/architecture.md`
+- `docs/setup.md`
+- `docs/testing.md`
+
+At minimum, after every milestone or feature change, update `docs/dev-log.md` with:
+- Date
+- Summary of what changed
+- Files modified
+- What was tested
+- What worked
+- Any known issues
+- Suggested next steps
+
+Use this dev-log format:
+
+```md
+## YYYY-MM-DD - Feature or Milestone Name
+
+### Summary
+Briefly explain what changed.
+
+### Files Changed
+- `path/to/file`
+- `path/to/file`
+
+### Details
+- Important technical detail
+- Important technical detail
+
+### Testing
+- What was tested
+- What the expected result was
+- What actually happened
+
+### Known Issues
+- Issue or `None currently known`
+
+### Next Steps
+- Suggested next task
+```
+
+If the protocol changes, update `docs/protocol.md`. If the architecture changes, update `docs/architecture.md`. If setup changes, update `docs/setup.md`. If testing workflow changes, update `docs/testing.md`.

.cursor/rules/project-overview.mdc

@@ -0,0 +1,29 @@
+---
+description: Fallout 4 Together project architecture and goals
+alwaysApply: true
+---
+
+# Project Overview
+
+Fallout 4 Together is an experimental Fallout 4 multiplayer mod. It uses a C++ F4SE plugin, a Python relay server, fake clients for protocol testing, and project documentation in `docs/`.
+
+The goal is to sync players across separate Fallout 4 instances by sending player transform and state data through a server, then representing remote players in-game with proxy actors.
+
+The current sync model includes player transforms, cell/worldspace IDs, heading, and movement state such as moving, speed, sprinting, sneaking, jumping, and weapon drawn.
+
+Preserve the existing server-authoritative relay architecture unless specifically told otherwise. The project is not trying to fully merge game worlds: each player runs their own local Fallout 4 instance, and the server distributes state updates between clients.
+
+Important project areas:
+- `plugin/src/main.cpp`: C++ F4SE plugin entry point and game integration.
+- `server/server.py`: Python relay server.
+- `server/fake_client.py`: fake testing client for protocol and relay checks.
+- `docs/`: architecture, setup, protocol, testing, and milestone documentation.
+- `docs/dev-log.md`: running project history and development log.
+
+Cursor workflow:
+- Read relevant files before editing.
+- Make minimal focused changes.
+- Avoid breaking already-working transform sync.
+- Avoid speculative rewrites or unrelated feature work.
+- Keep changes understandable for an iterative prototype.
+- Explain changes after applying them and mention assumptions made.

.cursor/rules/protocol-rules.mdc

@@ -0,0 +1,39 @@
+---
+description: Networking protocol compatibility and documentation rules
+alwaysApply: true
+---
+
+# Protocol Rules
+
+When modifying the networking protocol:
+- Update protocol documentation whenever packet structure changes.
+- Treat new fields as optional on receive unless the change is intentionally breaking.
+- Use safe defaults when a field is missing.
+- Do not rename protocol fields unless specifically requested.
+- Preserve unknown JSON fields where possible.
+
+Preserve existing field names, including:
+- `type`
+- `playerId`
+- `x`, `y`, `z`
+- `angleZ`
+- `cellId`
+- `worldspaceId`
+- `movementType`
+- `clientTime`
+- `serverTime`
+- `isMoving`
+- `movementSpeed`
+- `isSprinting`
+- `isSneaking`
+- `isJumping`
+- `weaponDrawn`
+
+When adding a new protocol field, make sure:
+- The plugin sends it when appropriate.
+- Receivers parse it safely and tolerate it being absent.
+- The server preserves or relays it.
+- `server/fake_client.py` is updated if useful for testing.
+- Relevant protocol documentation is updated.
+
+Protocol changes should avoid breaking already-working transform sync unless the requested change explicitly requires it.

.cursor/rules/testing-rules.mdc

@@ -0,0 +1,30 @@
+---
+description: Practical manual testing guidance for Fallout 4 Together changes
+alwaysApply: true
+---
+
+# Testing Rules
+
+When making changes, suggest practical tests the developer can run. Match the testing depth to the risk and scope of the change.
+
+Useful project tests include:
+- Running the Python server.
+- Connecting one Fallout 4 instance.
+- Connecting two Fallout 4 instances.
+- Running `server/fake_client.py`.
+- Checking `Fallout4Together.log`.
+- Verifying transform packets are sent.
+- Verifying remote player state is received.
+- Verifying proxy actor movement in `F4TTestCell01`.
+- Checking that movement state fields appear in logs.
+- Checking that server output receives and relays packet fields correctly.
+
+When a change touches multiplayer sync, include a short manual testing checklist covering:
+- Server startup and client connection.
+- Outgoing plugin packet fields.
+- Server receive and relay behaviour.
+- Remote state parsing.
+- Proxy actor movement or visible in-game result.
+- Relevant log output.
+
+If a test cannot be run locally, say so clearly and explain the remaining risk.