Original Platform Assumptions

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• CMakeLists.txt
• src/api/ApiServer.cpp
• src/api/Command.cpp
• src/main.cpp
• tests/api_server_tests.cpp

The Original Platform Assumptions encompass the technical requirements, architectural constraints, and protocol specifications derived from the "Minecraft: Pi Edition 0.1.1 alpha" reference target. This project serves as a source-reconstruction and native port, necessitating a strict adherence to the original game's behavior and programming interfaces while enabling execution on modern x86-64 systems.

The core objective is to reconstruct platform-independent game systems incrementally. This involves documenting original executable assumptions and establishing a protocol-compatible API test harness to ensure parity with the original TCP-based communication layer.
Sources: README.md:3-10, README.md:33-40, src/main.cpp:8-10

Protocol and Networking Assumptions

The primary interface for external interaction is the Minecraft Pi programming API, which operates over a specific network configuration. The system assumes a line-based text protocol where commands are sent as strings and responses are returned similarly, terminated by newlines.

Network Configuration

The project targets a specific port and protocol for compatibility with existing Minecraft Pi scripts and tools.

Feature	Assumption	Source Citation
Transport Protocol	TCP	README.md:14
Default Port	4711	README.md:14, src/api/ApiServer.cpp:115
Address Binding	INADDR_ANY (0.0.0.0)	src/api/ApiServer.cpp:211
Connection Handling	Multi-threaded listener	src/api/ApiServer.cpp:237-240

Command Structure

The protocol assumes a specific format for API calls: command.name(arg1,arg2,...). The parser must handle variations in line endings (e.g., \n or \r\n) and whitespace.

Cross-Platform Compatibility Layers

Since the original Minecraft: Pi Edition was built for ARM-based Raspberry Pi devices, the recompiled version must abstract socket handling and threading to support modern Linux and Windows environments.

Socket Abstraction

The implementation uses conditional compilation to bridge differences between POSIX sockets and Windows Sockets (Winsock2).

• Windows: Requires WSAStartup and WSACleanup for network initialization. It uses SOCKET types and closesocket().
• Linux/POSIX: Uses standard file descriptors (int), close(), and MSG_NOSIGNAL to prevent process termination on broken pipes.
• Timeouts: Receive timeouts are implemented using SO_RCVTIMEO with platform-specific DWORD (Windows) or timeval (POSIX) structures.

Sources: src/api/ApiServer.cpp:11-30, src/api/ApiServer.cpp:42-55, CMakeLists.txt:28-30

Build System and Standards

The project assumes a modern C++ environment to facilitate the reconstruction of legacy game logic.

• Language Standard: C++20 is required.
• Architecture Support: Targets x86-64 natively for both Windows and Linux.
• Threading: Relies on std::thread and std::atomic for managing the API server lifecycle without blocking the main game loop.

Sources: CMakeLists.txt:10-12, README.md:11-12, src/api/ApiServer.hpp:34, src/api/ApiServer.cpp:164

Data Logic and Parsing

The system assumes that all API communication is string-based. This implies that even numerical game data (like coordinates) must be serialized/deserialized as text.

API Interaction Flow

The interaction between a client (script) and the API server follows a synchronous request-response pattern per command.

Parsing Constraints

The parse_command logic assumes:

1. Commands must contain parentheses () to be valid.
2. Arguments are separated by commas.
3. Empty arguments between commas are preserved as empty strings in the Command structure.
4. The method name is everything preceding the first open parenthesis.

Sources: src/api/Command.cpp:29-55, tests/protocol_tests.cpp:24-34

Summary of Architectural Goals

The project adheres to a "Compatibility First" philosophy. This means reaching parity with the original 0.1.1 alpha behavior before introducing modern features. Key to this is the isolation of the API server from the core game reconstruction, allowing for a test-driven approach where the protocol behavior can be verified against known Pi Edition standards independently of the rendering or physics engines.
Sources: README.md:8-16, README.md:33-40