Lordfirespeed / NuGet-GameLib-Dehumidifier

An automated utility that maintains 'GameLibs' packages for Steam games.
GNU General Public License v3.0
10 stars 5 forks source link

Different Unity Package versions from upstream UnityEngine.Modules #31

Closed wherget closed 5 months ago

wherget commented 5 months ago

I encountered this while using the LethalCompany.GameLibs.Steam nuget package. The issue being that LethalCompany uses an older version of the Unity "Netcode for Gameobjects" package (https://github.com/Unity-Technologies/com.unity.netcode.gameobjects) than what ships in UnityEngine.Modules 2022.3.9 (as referenced by lethal-company/metadata.json). This leads to undefined references when trying to MMHOOK around in Netcode. I'm not sure of the ramifications of trying to ship this onto mainline nuget, but one possible solution I thought of would be to just ship the entire publicised Unity stack along with just the publicised LC assembly, instead of relying on the BepInEx nuget package.

My current workaround is to use a locally installed Netcode dll as dependency, but for CI/CD reasons I'd really love to ditch the requirement of having a licensed install on the build host, especially since that seems to be the aim of this package.

Lordfirespeed commented 5 months ago

UnityEngine.Modules 2022.3.9 doesn't contain netcode. The netcode assembly is in the Gamelibs package.

I'm confused by what you're trying to do. Knowing how NuGet and the buildsystem works, I seriously doubt the issue that you are having is related to the gamelibs package. 🤔

wherget commented 5 months ago

You're right. I've thrown the Unity.Netcode.Runtime.dll from 49.0.0-ngd.8 into dotPeek and sure enough, the symbols reported missing are all there. I must have confused one of the many disassemblies I'd been looking at. I'll keep banging my head against this then. Sorry to have been a bother and thanks for the clarification.