Closed DrPotatoNet closed 3 years ago
These changes seem related to issue #96
@notjuanortiz > Really good work here but there are so many file changes (some of which are unrelated). In the future, I would consider breaking this up into multiple PRs because it would make each improvement easier to test and review.
The file changes were kept to a minimum as all of the files changed were required in order to fully add Float2-4 and the code generation to better support use of standalone, all of the changes go hand in hand and wouldn't make much sense on their own which is why this is a single pr to improve StandAlone. Also, which file changes were unrelated? I looked back through the commits and none of the files changed seemed to be unrelated to my additions and changes listed.
@Crazy8ball System.Numerics
has Vector2, 3 and 4 etc as well. I was just wondering if it would be worth using something that is already there instead of reinventing the wheel here. If the issue with having to type UnityEngine.Vector3
and System.Numerics.Vector3
then one can always do that via an alias.
If this is merged, how would one go about choosing versions of the generated code that work stand-alone? Just select the non-Unity fields and avoid using the Unity ones? Or will multiple versions be generated?
Some other things I noticed whilst trying to use the code generated after testing these changes:
NetworkObjectFactory
still uses MainThreadManager.Run
, which is Unity-specific. It may be possible to execute the actions directly on a stand-alone server, or to have a shim MainThreadManager
that is not Unity-specific, but e.g. requires you to invoke its HandleActions
yourself, or do that on a separate thread automatically altogether.using BeardedManStudios.Forge.Networking.Unity;
, which may not exist or work on a non-Unity server. These are unused imports, so they can be safely removed.TestNetworkObject
) still use UnityObjectMapper
, and UnityNear
in places such as InterpolateUpdate
- rather than just Near
(think that was already posted in the feedback). This makes it hard to share the generated code between a stand-alone server and the Unity clients without making manual changes every time.EDIT: I figured it out, you have to uncheck "Generate MonoBehavior", or this new code will not be used.
Though it appears that you then lose the MonoBehavior
s and InstantiateX
methods in the generated NetworkManager
. Is it not possible to use the behaviours for the Unity clients and ignore them for the server end, where only the network objects are used?
I'm also wondering at this point if the develop
branch is stable and BC is guaranteed. If not, I'm wondering if it wouldn't be interesting to just drop support for Unity types entirely and replace them with these so all Forge data types are truly Unity independent; extensions exist to transparently convert between the two and this prevents using unsupported types by accident if you want a standalone server later on where appropriate alternatives exist.
By introducing "StandAlone" it looks like a user needs to pick between the two, it may not be clear to new users, and there seems little benefit in keeping the Unity types around in the first place.
I am no longer interested in perusing this as I no longer use Forge.
@DrPotatoNet That's fine, thanks for letting us know and your efforts.
I may look into applying your patches and mine on a new branch and creating a separate pull request.
EDIT: Done in #393.
These are more of a quality of life changes for those who use the StandAlone Server.
Changes as follows: -Added StandAloneNetworkObjectFactory for use with StandAlone Server -Added Float2, Float3, and Float4 as substitutes for Unity's Vector2, Vector3, and Vector4 (Color & Quaternion) for use with the StandAlone Server with operators for converting between them -Added code generation for Non-Monobehavior NetworkObjects