Skip to content

Add Forth Wall Attenna - #259

Open
cyberbalsa wants to merge 1 commit into
StarCpt:mainfrom
cyberbalsa:add-forth-wall-attenna
Open

cyberbalsa wants to merge 1 commit into
StarCpt:mainfrom
cyberbalsa:add-forth-wall-attenna

Conversation

@cyberbalsa

Copy link
Copy Markdown

Adds Forth Wall Attenna, a Space Engineers 1 gateway for controlling owned Programmable Blocks and Remote Control blocks from Python through an in-game antenna network. It supports discovery, PB source upload and execution, waypoint missions, and a terminal status dashboard.

This first listing is restricted to Pulsar Legacy (CLR) on Proton. The descriptor selects the three production source directories and pins Google.Protobuf 3.36.2. Pulsar compiles those sources into one assembly; tests and examples are excluded. Source is pinned to 68d608d.

Players also need the local hub block mod and Python client. The Plugin Hub setup instructions cover the companion installer, world configuration, and disabling an existing local DLL copy. The installer creates a private token file and leaves Pulsar profiles and Steam launch options unchanged. Game assemblies and vanilla model assets are not distributed.

The endpoint binds to 127.0.0.1:18751, requires bearer authentication, and rejects browser origins. Commands recheck local ownership and two-way antenna reachability. Networking and serialization run outside the game thread; game work uses a bounded queue with request deadlines.

Validation:

  • PluginHub's python3 test.py Plugins/ passes.
  • Release build against installed game assemblies: no warnings or errors; 14 C# tests and 17 Python tests pass.
  • The eight selected C# files compile together with Pulsar 2.4.3's compiler and .NET Framework 4.8 references. This standalone check hosted the compiler on .NET 9 with the SDK's compatible Newtonsoft.Json library.
  • Existing live tests on CachyOS/Proton passed radio-relay discovery, PB deployment and execution, waypoint flight, both antenna-loss policies, and large-grid hub status displays. Those tests used the local DLL installation; the combined Plugin Hub build has not yet been loaded in-game.

Laser-only and mixed routes, small-grid placement, and survival availability still need live checks. Multiplayer, dedicated servers, live steering, and PB RPC are not implemented.

@viktor-ferenczi

Copy link
Copy Markdown
Collaborator

New plugin review: Forth Wall Attenna

Scope: hub PR head 8feddce82df5efd9f3cf1743161e9b33d69b36c0, manifest Plugins/ForthWallAttenna.xml, source cyberbalsa/Forth-Wall-Attenna@68d608d. This is a full-repository review of a new registration: I accounted for all 54 tracked paths at the pin.

Summary: No agent-detected blockers. One Medium question: the <Runtimes>CLR</Runtimes> restriction may hide the plugin from Proton players whose prefix runs Wine Mono. There are two non-blocking notes, about the companion mod setup and the missing license.

Manifest

  • Hub validator (test.py Plugins/ at the PR head): All files validated.
  • Id is a fresh GUID, used by no other hub entry. The description is 844 characters, under the 1000 limit.
  • SourceDirectories selects src/ForthWall.Core/, src/ForthWall.Transport/ and src/ForthWall.Plugin/ (8 .cs files). Tests, examples, scripts, the Python client and the mod are excluded.
  • NuGetReferences: Google.Protobuf 3.36.2, the only non-game dependency in the selected source. It's published on nuget.org by Google Inc. (2026-09-17). No other hub plugin references Google.Protobuf.
  • The repository's own ForthWallAttenna.xml matches the hub manifest except for <Commit>.

Repository and pin provenance

  • Public repository owned by cyberbalsa, the manifest <Author>, created 2026-10-18. The pin is reachable from main.
  • main is one commit ahead (d14e828). That commit changes only README.md (a link to this PR) and the <Commit> line in the repository's own manifest. No tags or releases.
  • No committed DLL, EXE, native library, archive, submodule, symlink or LFS object. .gitignore excludes *.dll, *.exe and tokens.
  • MSBuild references: game Bin64 assemblies through $(GameBin) with Private=false, Google.Protobuf 3.36.2, and Microsoft.NETFramework.ReferenceAssemblies.net48 (build only). The test project is .NET 9 and isn't selected.
  • src/ForthWall.Core/Generated/Forthwall.cs and client/python/forthwall/forthwall_pb2.py are byte-identical to the output of the official protoc 36.1 release run on protocol/forthwall.proto.

From-source build

I compiled the three selected directories as one assembly with the settings of Pulsar Legacy's RoslynCompiler (Pulsar 013a108, v2.4.3): C# 14, Release, allowUnsafe, nullable context off, TRACE;NETFRAMEWORK;PULSAR. References were the game's Bin64 and Google.Protobuf 3.36.2. Result: 0 errors, 29 warnings, all CS8632 (nullable annotations outside a #nullable context). These are harmless because the loader doesn't enable nullable. The output has no http(s):// strings. I didn't load it in game.

Security

  • Network: one listener, TcpListener(IPAddress.Loopback, port), default port 18751 (configurable from 1024 to 65535 in gateway.xml). There are no outbound connections and no HTTP client.
  • Handshake: the server rejects any Origin header, requires Host to be 127.0.0.1:port or localhost:port, and checks the bearer token before the upgrade. That blocks browser pages and DNS rebinding. The token is 32 bytes from RandomNumberGenerator. Headers are capped at 8 KiB, messages at 1 MiB, connections at 8, with read deadlines.
  • Filesystem: writes stay in MyFileSystem.UserDataPath/Storage/ForthWallAttenna: gateway.xml (XmlSerializer of a fixed type), gateway.token, and gateway.log, which rotates at 1 MiB.
  • No process execution, dynamic assembly loading, P/Invoke or Harmony patches. The reflection targets fixed members: four private MyProgrammableBlock fields (m_currentAssembly, m_instance, m_terminationReason, m_compilerErrors) and MyIGCSystemSessionComponent.GetOrMakeContextFor. All of them exist in the current game build. If they change, Field throws and the session component disables the adapter.
  • Uploaded scripts go through IMyProgrammableBlock.ProgramData, so the game's own PB compiler and whitelist apply.

Compatibility / authority

  • LocalOwner is nonzero only when Sync.IsServer && !MultiplayerActive, and Execute rejects every request otherwise. Multiplayer sessions and hosted lobbies get NO_WORLD, so I see no path past server authority.
  • In single player, every command needs a working hub and a target owned by the local player with HasPlayerAccess, plus a two-way route. PBs use the IGC IsEndpointReachable(AntennaRelay) check. Remote Controls use MyAntennaSystem.CheckConnection.
  • Terminal control and action filtering applies only to the plugin's own hub subtypes. Other plugins' PB controls are left alone on ordinary PBs.

Findings

Medium: <Runtimes>CLR</Runtimes> may hide the plugin on Wine Mono prefixes.
Pulsar reports Runtime as Mono whenever Mono.Runtime exists. Hub entries whose Runtimes don't match are left out of the plugin list and not loaded. On the Proton prefix we test SE1 with, the game runs on Wine Mono, and Pulsar 2.4.3 logs Platform: Proton and Runtime: Mono. There this manifest would never appear. Your live tests don't tell which runtime your prefix uses, because Pulsar gives a local mscorlib DLL CLR;Mono.

Could you check the Runtime: line in your Pulsar info.log? If it says Mono, the hub entry won't show up for you either. Then the fix is <Runtimes>CLR;Mono</Runtimes>, after a test of the hub-compiled build on Wine Mono (Pulsar compiles there with Mono's framework assemblies, so a .NET Framework build doesn't prove it). If you only support prefixes with .NET Framework 4.8 installed, please say so in the description.

Non-blocking notes

Note: the block mod is outside the hub. The plugin does nothing without the hub blocks, and players get those only by cloning the repository and running install-local.py --pluginhub with Python 3.11+. Pulsar can add a Workshop mod's definitions to every world through a ModPlugin hub entry. If you publish mod/ on the Workshop and add it as a hidden ModPlugin dependency, the plugin works from the hub alone. The plugin already creates its token on first start, so the Python client would be the only part left to install from the repository.

Note: no license. The repository has no LICENSE file, so players and other developers have no explicit permission to use or modify the code. Please add one.

@viktor-ferenczi

Copy link
Copy Markdown
Collaborator

Could you please add an MIT License (if applicable) and make sure all runtimes where the plugin can run are enabled? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants