andrew
8c09e91534
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.
34 lines
1.5 KiB
Plaintext
34 lines
1.5 KiB
Plaintext
---
|
|
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.
|