When looking at the world map, you should be able to see icons for other players, along with your own. These icons should be color-coded per-player to tell them apart.

This video is recorded from the guest's POV. The guest activates the throttle of the DE2, then throttles down again. However, throttling down doesn't do anything.
At the end of the video, the host throttles down, this works as expected.

No Portforwarding

For players that cannot portforward and just want to simply play with their friends, they can use virtual local networks.
Luckily Zerotier is a good example of that which provides a simple interface.

(One person who is the network manager is the only person who sees everyone's actual real IP, and can figure out who is the one who hosts the game, and connect via Zerotier's local IP.)

It also works if one person is the host and the manager for the network.
All other players connect using the Managed IP.

• This also works with many other games and applications that require portforwarding!

Server Suggestions

Dedicated Servers, though it requires the game itself as well, would be an amazing option for those who play with a group but don't want to rely on one person to save or even save themselves. Now I don't really know how Dedicated Servers would really work, because most games have them as they're native to the game rather than it being an addon/mod.

Player nametags should be implemented similarly to Minecraft's in looks, with a config option to disable them. There should also be a config option to show the player's ping next to their name.

Instead of manually listing out the NetPacketProcessor#SubscribeReusable call for each packet, we should have an attribute that can be added to a method, and then it will get registered automatically.

The NetworkManager can have a static initializer that will search all methods for the attribute. When a method is found, its parameters will be checked. The first parameter will be for the packet, and the second, if present, will be for the user data (Usually a NetPeer). With this system, adding a new packet listener is as simple as creating the method with the packet as a parameter and adding the attribute.

GameParams holds a lot of miscellaneous information, mostly related to difficulty. All of this data should be synced when clients join the server to ensure they don't try to do things they're not supposed to and to ensure that the client-side predictions match the server.

Instead of updating player positions only when a packet is received, we should have an interpolation system that will fill in the gaps automatically. This can be implemented similarly to Valve's Source engine as documented here.

Once the interpolation system is implemented, the walking animation can be readded using the interpolated data.

Weather and time should be synced between the server and all clients. Theoretically, it should be as simple as syncing all parameters that WeatherDriver#GetSaveData/LoadSaveData uses when a client joins, then leaving further weather processing up to the client. If this proves to be unreliable over a longer period of time, we can re-sync it once every so often. To ensure time doesn't desync, sleeping will have to be disabled, and changes from the weather editor will have to be sent to all clients.

A permission system should be implemented to allow for more open lobbies while preventing people from trolling.

Permission should be broken down into groups, with two by default.
The 'Admin' group has all permissions, and the 'Default' group has limited permissions.

The admin group should not be able to be modified or deleted. The default group can be modified but cannot be deleted.
Other groups can be added, modified, and deleted at will.

The UI for selecting what group a player is in would look something like the following.

The UI for creating and deleting groups would look something like the following.

Permissions would exist for the following.

• Manual Switches: The ability to throw switches by clicking on them. The server would validate this with a simple distance-based sanity check.
• Remote Switches: The ability to throw switches with the comms remote.
• Delete Cars
• Rerail Cars
• Take Jobs
• Use Turntables
• Service Cars
• Fast Travel
• Purchase Licenses

As a precursor and requirement for implementing companies, the career state should be synced between the server and all clients. This includes licenses, garages, and money. All of which should be fully server-authoritative. The client should never give itself (or take away) a license, garage, or money. If a client does do any of those, it shouldn't matter as any actions requiring them will be requested by the client, processed by the server, with the result being sent back to the client.

Along with being able to manually join servers via an IP, port, and password, there should also be a server browser where players can find servers to play on. In the host settings, there should be an option to list your server in the browser, so people can opt out if they'd like.

We'll create a basic REST API for the backend to ensure compatibility between Steam and Oculus users. This will be written in 🦀RUUUUUUUUUUUUUUUST🦀using Actix. Servers will be stored only in memory, so there's no need for a database or any persistent data storage. When a server comes online, it'll send a POST request to the API containing its IP, port, whether it's password protected, and the current/max player count. Every minute the server will send the same POST request to the API to update the data and signify that it's still online. If a request isn't received from a server for over two minutes, it will be removed from the list. When a server shuts down or the owner removes it from the server browser, it'll send another request to the API to remove it from the list immediately.

There will be an advanced config option to specify the URL the server browser API is reachable at, so anyone can host their own instance if need be.

When loading the mod (I followed the full procedure with Unity 2019 & the powershell script package.ps1 to build the mod), Unity Mod Manager generates the following error after reading the info.json file: AssembleName is null

.NET 7 installed
Derail Valley build 95
Unity Mod Manager 0.27.5 (tried with version 0.27.3)

Summary of log file:

[Manager] Parsing mods.
[Manager] Reading file 'D:\Games\Steam\DerailValley\Mods\Multiplayer\Info.json'.
[Manager] Sorting mods.
[Manager] Loading mods.
[Multiplayer] Version '0.1.0'. Loading.
[Multiplayer] [Error] AssemblyName is null.
[Multiplayer] Loading time 0,00 s.
[Manager] FINISH. SUCCESSFULLY LOADED 0/1 MODS.

Thanks for your help!

Syncing job creation and job paper physics

Skins should be synced when using Skin Manager and assuming all clients have the skin installed. If a client doesn't have Skin Manager or the selected skin isn't installed, the default skin will be shown.

I'm trying to build this project and having to guess what dependencies I need based on the code and .csproj. I'm stuck on acquiring I2.Localization, that seems to be a paid Unity plugin...

While in-game, there should be a button that can be held down to open a player list. This can be implemented similarly to Minecraft's player list, just a basic popup with each player's username and ping. The easiest way to go about this would be implementing it into the top-left corner of the UI that's shown when pressing alt.

The confirm button is deactivated unless a password is typed.

Train synchronization will be an enormous task that must be implemented in several steps, roughly outlined below.

• Spawning, including preventing the client from spawning trains.
• Removal.
• Derailed state.
• Accessories (couplers, handbrakes, etc).
• Position.
• Controls.
• Simulation state.
• Cargo.
• Brake system.
• Car Damage.
• Cargo Damage.

How do I use the mod after I installed it?

Hi Insprill,

I noticed this project doesn't currently use a tool like Dependabot for dependency management. I was wondering if you'd be interested in considering it.

Dependabot automates keeping dependencies updated and helps identify potential security vulnerabilities. This can save you time and effort in maintaining the project.

Here's some information about Dependabot for your reference: Link to Dependabot quick start guide

Thanks for your work on this project!

I want to contribute to this mod, but I don't know how exactly it works, whether by simply building the mod then installing it in the original game or building the entire modded game with Unity.

I have an idea. Based on the current map of DV, if there are too many online players, it will cause a lot of train congestion. Can we combine the Remote Dispatch module to open a function specifically for controlling the train operation of the entire map (although we still need to solve the problem of player task system and switch synchronization before implementing this function), but we still hope to develop this function in the future。
我有一个想法，按照DV目前的地图来说，如果在线玩家一多，那将会造成列车大堵车，能否结合RemoteDispatch模组，开放出一个功能，专门用来控制整个地图的列车运行情况（虽然实现这个功能前还需要解决玩家任务系统和道岔同步问题），但还是希望以后能开发出这个功能

Dedicated server support can be implemented by making use of SteamCMD. Once the game is installed on the host of choice, it can be started with the -batchmode and -nographics flags. This will prevent the game from trying to load a graphical environment. We can then check the arguments for one of our own, being which save to load, and from what user. If that argument is present, and the user and save are valid, we can automatically load into the session, which will then be ready for players to join.

Add support for showing all players on the Remote Dispatch map.

When connected to a server, there should be a chat box that players can use to communicate via text and that the server can use to send players messages (clients joining/leaving). This should be implemented similarly to Minecraft's chat. New messages should appear briefly before fading out, and the entire history can be brought up when entering mouse mode with left alt. There should be a keybind to start typing, along with being able to click on the textbox in mouse mode.