Second Instance Network Failure

[githubawn]

Prerequisites

• I have searched for similar issues and confirmed this is not a duplicate

Game Version

• Command & Conquer Generals
• Command & Conquer Generals: Zero Hour
• Other (please specify below)

Bug Description

0127.1.mp4

Hypothesis: The current networking implementation uses fixed ports for LAN communication, which likely leads to initialization failures when multiple instances run on the same machine.

Lobby Port: Fixed at 8086 (LAN_LOBBY_PORT)
Game Port: Based on 8088 (NETWORK_BASE_PORT_NUMBER)
When attempting to run multiple game instances on the same machine (e.g., for local testing or split-screen setups), the second instance fails to bind to these ports because they are already in use by the first instance.

Reproduction Steps

Open the game executable to launch the first instance.
Navigate to Multiplayer -> LAN Lobby.
Without closing the first instance, launch a second instance of the game on the same machine.
Attempt to navigate to Multiplayer -> LAN Lobby on the second instance.
Observation: The second instance displays an error message and returns to the previous menu (or fails to initialize network capabilities).

Additional Context

Dynamic Port Allocation
File: Core/GameEngine/Include/GameNetwork/NetworkDefs.h & Transport.cpp
Action: Update Transport::init (called by LANAPI::init for Lobby and OnGameStart for Game) to attempt binding 8086/8088 first. Only if those are busy (ADDRINUSE), iterate through a range (e.g., +1 to +25). This guarantees Instance 1 remains on standard ports (Legacy Compatible).

Update Discovery/Broadcast
File: Core/GameEngine/Include/GameNetwork/LANAPI.h & LANAPIhandlers.cpp
Action: Update LANAPI::sendMessage to iterate and send discovery packets to the entire port range (e.g. 8086-8113), ensuring instances on non-standard ports receive them. Write the Host's actual listening port into the existing "Port" field of Slot 0 in the GameOptions string.

[xezon]

Did you select 127.0.0.N ip in Options Menu? If not then, that is the mistake. As far as I am aware it has worked for all devs.

[githubawn]

Thanks for the suggestion

I checked the Options Menu, but both the 'Online IP' and 'Network IP' dropdowns only list my physical/virtual adapter IPs; the 127.0.0.N loopback range isn't being populated in the UI.

Even when manually forcing GameSpyIPAddress/IPAddress = 127.0.0.1 (or .2) in options.ini, the engine appears to prioritize either the first bound or selected physical adapter.

[Caball009]

Perhaps you need to compile with CMake flag RTS_DEBUG_MULTI_INSTANCE enabled.

[Stubbjax]

Perhaps you need to compile with CMake flag RTS_DEBUG_MULTI_INSTANCE enabled.

I initially thought this too, but wouldn't it be impossible to have multiple instances running on the one machine without this anyway?

[Caball009]

Perhaps you need to compile with CMake flag RTS_DEBUG_MULTI_INSTANCE enabled.

I initially thought this too, but wouldn't it be impossible to have multiple instances running on the one machine without this anyway?

Yeah, I suppose so.

[githubawn]

I'm running it on: https://github.com/wunnr/partydeck
Didn't know it had a flag for this, i now compiled it with RTS_DEBUG_MULTI_INSTANCE on.

The 127.0.0.N shows up in options now.

But Partydeck isolates the mutexes so they still all try the same IP:Port.

[Caball009]

But Partydeck isolates the mutexes so they still all try the same IP:Port.

I'm not sure what that means, but maybe you can implement something like that with another synchronization primitive. If you don't care about VC6, you could use something from modern C++.

[Caball009]

@githubawn I don't know if you still need this, but maybe this PR can help: #887