News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Persistent history for manually entered servers

Started by victor_18993, July 25, 2026, 07:58:09 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

victor_18993

Hi Prissi,

This is a follow-up to an older request concerning a persistent history of manually entered multiplayer servers. Since the original topic is now closed, I have opened this new topic to present a working and tested patch.

01-recent-servers-dialog.png

At present, a manually entered server address is retained only for the current session. This patch adds a local MRU history containing the last ten manually entered servers that were successfully connected to.

The existing public server list remains unchanged. Servers selected from the public list are not added to this history.

The interface provides:

- a recent-server selector;
- an optional local alias, displayed as "Alias (address)";
- removal of individual entries;
- import and export of shareable server lists.

Only the server address and its optional alias are stored. No passwords, player nicknames, pakset information or game data are saved.

The data is stored as a small, versioned UTF-8 CSV file named `recent_servers.csv` in the Simutrans user directory. It is deliberately not encrypted because it contains no credentials or private connection data. It is never included in a savegame or synchronized over the network.

A manually entered address is recorded as pending when the connection starts and is added to the history only after `network_connect()` completes successfully. Failed connection attempts are discarded. Entries are deduplicated by address, ordered with the most recently used first, and limited to ten.

Persistence and import/export include the following safeguards:

- saving through a temporary file followed by checked replacement;
- transactional imports;
- rejection of unknown file-format versions;
- a 64 KiB import-size limit;
- preservation of the current history if importing or saving fails;
- explicit confirmation before overwriting an exported file.

Scope of the patch:

- no savegame-format change;
- no network-protocol change;
- no server-side change;
- no new dependency;
- no native platform-specific file dialog;
- no change to the existing public server list.

Validation on r12103:

- Simutrans builds successfully;
- all 61 dedicated automated checks pass;
- a failed connection creates no history entry;
- a real connection to `simutrans-forum.de:13355` completed `NWC_JOIN`, `NWC_SYNC` and `NWC_GAME`, and created the expected local entry;
- the recent-server dialog and overwrite confirmation were tested visually in game;
- the complete patch applies cleanly to r12103.

I have attached the complete patch and two screenshots.

Before reducing or extending the patch, I would appreciate your opinion on three design points:

1. Is a separate `recent_servers.csv` file in the user directory acceptable, or would you prefer this state to be stored in an existing configuration file?
2. Should import/export be included in the first version, or would you prefer an initial patch containing only the history, aliases and removal?
3. Is a fixed limit of ten entries reasonable?

Regards.
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)

prissi

Honestly, with less than three active servers ... (Of course I wished there were more servers.) Also, simutrans reconnects on the last used server already.

I honestly never use the server windo at all, rahter use "net:..." in the open window (which also bypasses the version check) or use "-load net:..." on the command line. Then one can have several versions as shortlinks.

Finally, I am not a fan of a big dialog, and import and export is really not needed. Just read the csv file when opening and read and save it when joining a server.

Also the servers have a name already. A second name is slightly confusing. What one could do is looking in the list for a server with the same name and remove this entry when adding a new conenction to a server with the same name. (Especially private hosted servers could be prone to changing IP number every 24h.)

victor_18993

Thanks, Prissi. That makes sense.

I agree that the current version is too large for this feature. I will reduce it to a minimal recent-address history integrated into the existing server window: no aliases, no import/export and no separate management dialog.

The file would simply be loaded when opening the server window and updated after a successful connection, as you suggest. I will also look at using the server-reported name to replace an older entry when a private server changes address, while keeping address-based deduplication as the fallback.

I will check how small the resulting patch becomes before taking it any further.
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)

victor_18993

Thanks for the feedback. I have cut the patch down as you suggested: no dialog, no
import/export, and no separate alias. It is now just the small piece you described.

What it does now:

- The multiplayer window reads recent_servers.csv when it opens and shows the
  addresses in a small combo box under the manual-entry field.
- Picking one copies the address into the entry field (you still Query, then Join).
- When a manual connection succeeds, that address is saved to the file. Nothing
  else writes it - picking a server from the public list is not recorded (those
  are already in the list), and a failed attempt is not recorded.
- No second name: the combo shows the address exactly as typed. No management
  dialog, no import/export, no buttons.

For servers whose IP changes (the dynamic-IP case you mentioned): the list stores
the address string the player typed, so if they connect by a stable hostname it
stays stable; a raw IP that changes is simply remembered as a new entry, capped at
the ten most recent.

The file is a tiny versioned CSV under the user directory (one address per line),
written atomically, and a damaged or foreign file is ignored rather than lost.

Base r12109. Reduced patch: the model plus two small hooks (load on open, save on
join), a single combo, one translation string. The non-graphical logic keeps a
stand-alone unit test (60 checks). Standard test
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)

prissi

I wonder, if it isn't better have every server that had been loading a game in the recently used list. Because, as said, I usually open private servers via the load window. But I think it would be nice to have those recorded too. So Server list and below last used list. And since working on this window, maybe also the severlist is better as a combobox to avoid all resizing issues. The last used would parse the serverlist to find if the IP of a known server name had changed and change the last used IP accordingly, maybe?

Server list
COMBO

Last Connected to
COMBO

Query ...

victor_18993

I have reworked the patch against r12110, taking both of your replies into account.
There are three attachments:
  • the functional patch;
  • the unit-test patch, with its CMake targets kept separate so the main patch remains easy to review on its own;
  • and a short document with implementation details and screenshots.
The history now records every server from which a game has actually been loaded, regardless of how the connection was started: from the public server list, the manual address field, the load window, or
-load net:... on the command line.
This also allowed me to remove the old code that distinguished connections made through the manual field. As a result, the new patch is actually smaller than the previous version, even though it covers more cases.
Servers are now tracked by name rather than only by address. Each entry stores both the announced server name and its current address, so the user does not need to enter a second name manually.
When the public server list is refreshed:
  • an existing entry without a name adopts the announced server name;
  • and when a known server name appears at a different address, its stored address is updated.
This should prevent servers with frequently changing IP addresses from creating a new history entry every day.
The server list is now a combobox, following the layout you suggested:
Server list
COMBO
Last Connected to
COMBO
The history is stored as a small CSV file in the user directory. Files written by the previous version of the patch still load correctly, and older builds reading the new format will still obtain the server addresses correctly.
The patch builds cleanly at commit
acf4651e0, with no new warnings. The unit test currently contains 80 checks, all passing, and both patches apply cleanly to a fresh tree at that commit.
I also checked the dialog visually in both populated and empty states.
The two things I have not been able to verify fully are an end-to-end connection to a real server and whether the combobox preserves the same online/offline colouring that the old scrolling list used.
There are also two small UI decisions where I would appreciate your preference.
First, when the combobox is opened, its dropdown covers the upper half of the "Query server" row, as shown in figure 3 of the document. This is consistent with the other comboboxes in Simutrans—the city list behaves in the same way—so I left it unchanged rather than giving this dialog special behaviour.
Second, with the broader tracking described above, a server selected from the public list is also added to "Last Connected to" once a game is loaded from it. That seemed to match the intention of recording every server from which a game has been loaded. If public-list servers should be excluded, the change is only a one-line condition.
En la vida todo son vivencias y cada una de ellas nos hace mas grandes,¿Como de grande eres tu? :)

prissi

I think adding everything is how "Last used" is expected from users. Anyway, I am leaving today on a 48h hour journey to Germany (flight-flight-hotel-train) and even then may have little time for testing further, so it may take a few dazys to submit.