the SDL3_net implementation was causing blocking behaviour and was
difficult to debug and has bad docs due to not being released. Caused
crashes all over. so moved to Asio. This thing took so damn long as this
also had it's issues!
- All networking now uses Asio's async callback model.
- TcpConnection class encapsulates logic for a single client-server
connection, managing socket and message framing.
- Implmented thread-safe queues for handling incoming and outgoing
messages between the network thread and the main application.
- Refactored ClientNetwork and NetworkManager, the primary client and
server networking classes have been rewritten to use the new
asio-based architecture.
- Player objects on the server are not managed by std::unique_ptr to
ensure proper lifetime management and prevent memleaks.
- VFSManager is now a single instance on the server, passed by reference
to new players, avoding redundant script loading for every connection.
- Resolved server crash that occured immediately upon client connection.
This was traced to an object lifetime issue within Asio's async
handlers which was fixed by simplifying the send operation.
Client architecture has been refactored to be fully
server-authoritative, remove the previous "hybrid" model that supported
both local and remote command execution, that was a stupid idea.
- Client now connects to server on startup.
- The local command processor and VFS have been removed from the
Terminal class.
- All command processing is now handled by the server.
- The client is now just a thin client essentially
I'll in the future enable single player mode by running the server on
the local machine in a separate thread.
OK, this commit finally implements the Copy-on-Write architecure I spoke
about in previous commits.. It also refactors command execution to be
safer and more extensible.
To enable CoW and centralise state-changing, command scripts no longer
modify the VFS directly. Instead, they return a table describing their
intended action '{ action = "rm", target = "file.txt" }'. The C++
CommandProcessor is then responsible for interpreting this and executing
it safely.
Refactors the Virtual file System creation process to improve memory
efficiency at scale. This is laying the ground work for a copy-on-write
system.
Previously, each new VFS instance was a full copy, which won't scale to
a large number of NPC's. Especially now that we are loading in entire
Lua scripts.
- Added VFSManager class which now manages the lifecycle of all VFS
instances.
- VFSManager creates a single "template" VFS on initilisation. The
template holds the shared, read-only directories like '/bin' and their
command scripts.
- When a new VFS is created (for a client or NPC), it links it's 'bin'
directory to the shared template's '/bin' by pointer rather than
creating a copy of it.
this makes sure the content for *all* common command scripts exists in
memory only once, regardless of the number of NPC's we will later
generate.
Over the past couple of commits, the build process now automates the
dependenices you'd normally compile from source.
This commit is focused on laying the foundation for scriptable in-game
commands using Lua.
- sol2 and lua5.4 are the new project dependencies.
- Created a new 'LuaProcessor' class to manage a Lua state and eecute
scripts.
- The 'CommandProcessor' now contains a 'LuaProcessor' instance.
- Replaced the hardcoded c++ 'ls' command with a system that executes a
'/bin/ls.lua' script from the Virtual File System.
- Implemented C++ -> Lua bindings for the 'vfs_node' struct, allowing
Lua scripts to inspect the VFS and perform actions (i.e, list files).
This is the beginning of the remote session functionality. It allows
players to connect to different NPC systems via an 'ssh' command.
*Server*
- Can now manage a world of multiple NPC file systems that are
identified by IP addresses.
- Implemented SSH command to allow connection to remote NPC systems.
Each remote session is managed via a 'CommandProcessor'.
- 'exit' command causes the remote server to terminate the client
connection
*Client*
- Terminal can enter a 'remote' state via the SSH command which sends
subsequent commands to the server.
- the local 'exit' command will close the terminal window.
- Refactored UI object ownership to prevent memory leaks and ensure
proper cleanup when a window is closed or the terminal application.
