Official Client Bridge Guide

This guide explains how to make the official aLogin.exe connect to FloatPilot first, while FloatPilot forwards the same TCP session to the official server.

Important: FloatPilot's server.ini and the official client's SERVER.INI serve different purposes. FloatPilot must keep the real official-server IP. Only the official client's SERVER.INI should point to the local BridgeHost. Live compatibility has not been verified for every official client version.

Keep the Two Server Configurations Separate

Section and key layouts differ between official versions. Change only the server IP field that already exists in that version; do not invent a new key.

Quick Start

1. Start FloatPilot and open the login window.
2. Select the account, official server, and character slot.
3. Set “Connection Method” to aLogin Bridge.
4. Press “Login” and wait for the account list to show Waiting for aLogin.
5. Point the official client's SERVER.INI to that account's displayed BridgeHost:6414.
6. Start the matching aLogin.exe.

The login window no longer exposes a bridge-control selector or a separate endpoint-info block. Bridge control is fixed to Shared. The account list still shows relay state and endpoint so that SERVER.INI can be configured.

During a normal connection, the account state progresses through:

Waiting for aLogin
aLogin connected
Connecting to official server
Official server connected
Game logged in

Bridge Control and the App SEND Gate

The bridge always uses Shared: aLogin and App packets enter one bounded outbound queue and are written in order through the same official-server connection. Legacy Observation or AppControl values remain readable from old INI files for compatibility, but runtime always normalizes them to Shared; they cannot bypass the gate.

• Raw aLogin client→official and official→client TCP traffic remains transparently relayed. It is not dropped or rewritten while the gate is locked.
• App-originated SEND is not written to a socket until the current bridge generation receives and assembles the official server→client 23/05 frame. The call returns an explicit unsent result before that point.
• After that exact session's 23/05 arrives, App SEND unlocks only for the same generation. Fragmented and coalesced TCP reads are parsed as frames rather than matched on raw chunks.
• Disconnects, reconnects, new generations, and late frames from an old generation lock App SEND again. An old session's 23/05 cannot unlock a new session.

The parser-confirmed 23/05 state also marks the exact session as Game logged in; UI success no longer relies on an IsAbleToControl inference.

Local Endpoints and Multiple Accounts

The Bridge always uses TCP port 6414, with a different IPv4 loopback address for each account:

Account A: 127.0.0.1:6414
Account B: 127.0.0.2:6414
Account C: 127.0.0.3:6414

Production accepts only 127.0.0.0/8. LAN addresses, 0.0.0.0, IPv6 ::1, and duplicate BridgeHost values are rejected. A valid saved address is reserved first, so it does not move when the account list is reordered.

When using multiple accounts, use a separate official-client folder for each one whenever possible. This prevents different aLogin.exe processes from overwriting one SERVER.INI.

Use the App Through the Same Session

After the account reaches Game logged in, the App and aLogin share the same bridge connection. “Teleport → Return to Playground” is a simple smoke test:

1. Confirm the character is not in battle, dialogue, trade, or another busy state.
2. Open “Teleport” from FloatPilot's top menu.
3. Press “Return to Playground”.
4. Wait for the official-server response before starting another action.

If 23/05 has not arrived, the session is disconnected, or the generation is stale, the App rejects the send and does not optimistically change local map state. aLogin's transparent relay can still handle its own traffic.

Disconnect and Reconnect

• Closing aLogin, losing the official upstream, stopping the App, or stopping the account cleans up that account's relay, sockets, listener, and outbound queue.
• One failed account does not stop listeners or relays owned by other accounts.
• Restarting the same account reuses its saved BridgeHost, but App SEND waits for 23/05 from the new generation.
• Old-session packets, state callbacks, and App commands carry generation tokens and cannot be applied to a new session.
• Normal App shutdown waits for Bridge cleanup with a bounded timeout; no manual listener shutdown is required.

Common Problems and Troubleshooting

It stays at “Waiting for aLogin”

1. Confirm that FloatPilot completed the account-login flow.
2. Confirm that you edited the official client's SERVER.INI, not FloatPilot's server.ini.
3. Confirm that the IP exactly matches the account-list BridgeHost.
4. Confirm that the port is 6414.
5. Confirm that you started aLogin.exe from the correct client folder.

It shows listener-unavailable

Another process is using that 127.0.0.x:6414. Close stale FloatPilot/aLogin processes and confirm that two accounts are not sharing a BridgeHost.

It shows upstream-connect-failed

Confirm that FloatPilot's own server.ini still contains the real official-server IP. Do not change that file to 127.0.0.x.

aLogin disconnects immediately

The official version may use a handshake, header, version, or encryption flow that has not been confirmed. Preserve the client version, SERVER.INI, Bridge structured log, and any required raw capture for evidence-based analysis.

An App action has not been sent

Confirm that the account received server→client 23/05 for the same generation and is still connected. Before that frame, only aLogin's transparent relay continues; App SEND is explicitly rejected.

Compatibility Boundary

Confirmed behavior includes local endpoint allocation, fixed port 6414, transparent TCP relay, fixed Shared outbound, the parser-based 23/05 gate, same-session outbound, generation cleanup, and multi-account isolation.

Still unknown:

• Live handshake, header, version, encrypted login, and complete login compatibility has not been verified for every official aLogin.exe version.
• Official server-to-client state parsing still lacks live golden captures for each version; a static parser cannot replace wire evidence.
• The meaning and timing of 23/05 across all official versions still require live capture confirmation.

Final Checklist

• FloatPilot's server.ini still points to the real official server IP.
• The official client's SERVER.INI points to the account-list BridgeHost:6414.
• The login window uses aLogin Bridge as its connection method.
• FloatPilot reaches Waiting for aLogin before aLogin.exe starts.
• Multiple accounts use different 127.0.0.x values and preferably separate client folders.
• The exact session has received 23/05 before the App performs actions.
• Client version, configuration, and diagnostics are preserved when investigating compatibility.