Use outside of unity

[leiunn]

Version Number and Operating System(s):

git clone from master

Windows 10

Expected behavior:

I wanted to use Forge Networking Remastered outside of a Unity project (as mentioned in the readme).

Actual behavior:

Since the decision to move away from building ddls and moving most of the files to another place it seems that you can not use it without unity any longer.

If I'm wrong please give a short explanation on how to do so because I wan't able to find any documentation about that topic.

Steps to reproduce:

[Optional] Discord Username:

[Crazy8ball]

Will look into setting up the solution so that it can be built outside of Unity, I made these changes and thanks for bringing this up.

[NoTuxNoBux]

I'm trying out Forge for a non-Unity server a Unity client, but am getting more and more confused the further I progress.

Alloy was "released in 2020", implying this is the latest version, yet it is located on develop, implying it's not yet stable.

After following the Alloy instructions, I'm getting errors due to code importing UnityEngine and other Unity things, even though the README states that Forge was designed to work outside of Unity as well. I've now extracted just the Networking folder of Alloy, which seems to work in a first test - bar an unused import UnityEngine statement in SQPServer that I could easily remove without further problems.

For the Unity client, I see the tags in this repository haven't been updated since 2017, which I'm guessing is version 2.0 still and not Alloy. The instructions tell me I can install from the asset store, which has a more recent version from 2019; great, but... is this Alloy or 2.0? Looking at the code, it's different from the Alloy code I extracted for the server on develop and still has banners around "Heavy development".

If this sounds angry or insulting, it is not my intention; I'm just confused: is Alloy ready for production or not, if so, is it available on the asset store already, and should I be using it outside Unity?

(Also, importing folders into projects is unfortunate, since now all of the Forge code is cluttering my Git and I cannot easily update to new bugfix versions using a package manager.)

[JacobChrist]

These videos are a year old, but is looks to me like Alloy is meant to play a little different roll than ForgeNetworkingRemastered:

https://www.youtube.com/watch?v=qsJZ4Tc-_tc&list=PLm1w78-UUlMI2oX8tlXFnBAT8oj06GMgN

As far as updating the code in unity, just clone the latest then copy over to your unity project. This is helpful incase you need to modify any of the FNR code. This way you can diff the new code with any change you made. I've only been using it for a day and we need to modify the MultiplayerMenu code.

[NoTuxNoBux]

@JacobChrist Thanks for the information.

I'm also wondering: is it even possible to use Forge for an external server without Unity when you want to work with the "networked objects"?

I've spent the better of two days now puzzling together information from the docs and fighting with actual data synchronization and RPCs not being properly sent over the network. All complete examples appear to have the server as Unity project, where I'm looking for an external non-Unity server with Unity clients communicating through it. Most of the questions that arise from this are left as an exercise to the reader. What does a stand-alone non-Unity server need to do beyond new TCPServer(32) and Connect to get synchronization of networked objects to work for Unity clients?

• Do I need to manually route TCP requests or RPC calls from one client to others?
• I have a simple busy loop, do I call NetworkObject.Flush(server); every so often?
• Will RPC requests sent by clients automatically be sent to other clients by Forge's standalone TCPServer? Or is this only the case in Unity?
• Do I need to invoke the NetworkManager (impossible, as it has Unity dependencies) to handle objects every so often?

The docs nicely explain how everything works, but most of it is about having the server inside a Unity project, where instantiation of the same contracts and such is possible. I'm struggling to get my RPC requests delivered to even the same client with Receivers.All.

A more extreme case would be where the TCP server end is written in Node.JS or something not related to Forge. Is such a thing possible?

[NoTuxNoBux]

(Disclaimer:) I haven't gotten everything working yet and cannot confirm that "everything will work", but I can answer some of my own questions now, which will hopefully help someone and may provide a jump start for others reading this. :

• Yes, it is possible to use Forge in a stand-alone non-Unity C# project. I extracted the Networking folder for this, with a few minor caveats, see also above.
• You do not need to manually route TCP requests to clients from the server. The key I was missing is that you need to share the code generated by the Network Contract Wizard from the Unity editor on your clients with your server, or the server will not recognize objects clients want to instantiate. You need to execute NetworkObject.Factory = new TheGeneratedNetworkObjectFactory(); in the server or creations are silently ignored. If all is well, you should see new objects coming in on the server by listening to server.objectCreateRequested, but there are some caveats with this, currently:
  • Unity-specific types such as Vector3 cannot be used as the server will not know them. You can however use multiple floats or Float3 and friends, which are added in StandAlone Quality of Life Improvements #310 .
  • Generated code may still contain some (easily fixable) Unity references, which you appear to need to fix yourself for the time being, see also the pull request above.

I'm still calling NetworkObject.Flush(server); in my busy loop every so often. I still have to figure out if that is necessary.

I've also not yet gotten RPCs to work. This appears to be due to the server buffering them indefinitely because ClientRegistered is never set. Registration needs to be completed on the server for these objects for RPC's to work.

EDIT: NetworkObject.Flush(server); in my busy loop every so often does not appear to have any effect, so I removed it. But I did need to call server.IterateNetworkObjects((networkObject) => networkObject.InterpolateUpdate()); every so often to have the server remember the data of the network objects the way Unity clients do. (If you don't, the server will not read updates and, if a client then spawns an object, moves it, disconnects, and another client later enters, the old positional data of the network objects will not be synchronized to the new client, as the server must send it to them, which never kept up with it in the first place.)

RPCs work now. The server was indeed buffering them indefinitely because they were not "registered" yet. I solved this by listening to server.objectCreated, registering the RPCs and then calling networkObject.RegistrationComplete(); on the passed object.

Note that this also implies that you must register the same RPCs on the server as on the client, and on the client they are registered in the mono behavior, which you cannot use on the server, so you must mimic the same RPCs and their order. NetworkObject itself already registers four RPCs, so you may still need to add SetupTransform if your client has it, and then your own RPCs. After that, I could send RPCs from the client to other clients and the server.