convert to Unity package?

[radiatoryang]

Would you be open to converting this repo to follow the Unity package format? https://docs.unity3d.com/Manual/cus-layout.html (add package.json, rename some folders, add .asmdef, etc)

I can submit a PR if you're open to it but busy

[wfowler1]

Hm, you know, that's a pretty good idea. Probably better than having people check out the source using Git or downloading all the files some other way. I guess I just figured grabbing everything was easy. Lately I've been thinking of how to distribute builds of other projects, and this would be perfect for this one.

Go ahead and make a PR, I'm not sure what all is involved in this and I don't like the idea of committing a bunch of META files into the LibBSP repo. But I'd be happy to look at anything you come up with!

[radiatoryang]

What's nice about the package format is that it's relatively "backwards compatible" too -- if you don't want to deal with it as a package, you can still just unzip it into the Asset folder, and it'll work as usual. Or even manually install it as a "local package" by cloning into the Packages folder?

re: LibBSP, I think the best solution there would be to run a GitHub workflow action on Unity3D-BSP-Importer that automatically checkout LibBSP repo and compile it into a DLL, then copy it over into the package

This is similar to what the Unity plugin Yarn Spinner does: they have a core generic library repo, and then a Unity wrapper repo. The Unity repo has a GitHub action that automatically grabs and compiles the core library DLL and creates a PR: https://github.com/YarnSpinnerTool/YarnSpinner-Unity/blob/main/.github/workflows/update_dlls.yml

If you wanted an ecosystem of different Unity packages that rely on LibBSP though, on the LibBSP repo you should maintain a "upm" branch with the DLL and meta file, so that other packages can import it as a dependency. Again, GitHub workflow actions can probably automate that for you somehow.

Anyway! I'll start working on this and submit a PR

[radiatoryang]

progress on this: I have the GitHub action working on my fork... it compiles LibBSP into a DLL, copies it into the repo, and then creates a PR for the new DLL

https://github.com/radiatoryang/Unity3D-BSP-Importer/blob/master/.github/workflows/update_dlls.yml

https://github.com/radiatoryang/Unity3D-BSP-Importer/pull/3

some stuff to consider:

• your LibBSP .sln and .csproj use lowercase "libBSP" in the filepaths, which breaks compiling on any OS with case-sensitive paths (anything not Windows)
• it still has to use a Windows 2019 runner anyway, because that's the only one that still includes .NET 4.x libraries for some reason
• the Action uses ~1.5 GitHub minutes on a Windows 2019 runner, so that bills you ~3-4 minutes per run... which is easily within the free 1000 minute monthly allotment, so don't worry about it, just fyi

questions:

• currently set to manually run via web interface... did you want this to be automatic (e.g. when you push to LibBSP main branch?)
• might be good to use version tags on LibBSP repo?

[wfowler1]

Neat! I wouldn't want to automatically update the DLL in this project since sometimes I make API changes that need refactors. I'd prefer if I have to click a button to make it happen. I'm not sure what would be involved with version tags, but if it would make things easier I can start doing that.

I can fix the paths in the SLN and CSPROJ files, I didn't even realize this was going on but it's a pretty simple fix.

I can update the .NET framework version if need be, there's nothing version specific in there that would break if I do as long as the System.Numerics namespace is available. I keep the syntax compliant with very old C# versions so it can be used with extremely old versions of Unity.

[wfowler1]

Is there anything else you need from me? I'd love to finish this up!

[radiatoryang]

Oops sorry I forgot about this... I think it's ready, theoretically?... But I can't confirm since my fork that automatically compiles the DLL is stuck on the most recent version of LibBSP, which has all those refactoring and renaming work (e.g. from March 23 onwards)... but the Unity code here isn't updated to reflect the renamed variables and such.

So I think the way to proceed is:

1. you update the LibBSP submodule here to the most recent version, and fix up the Unity code here like you normally would

2. then we can tackle errors specific to this issue / PR?

currently most of the compile errors seem to be from the refactor (e.g. looking for BSP.nodes instead of BSP.Nodes)

but I think there might be an issue with Unity's version of System.Numerics (might require Unity targeting .NET 4.x or later, which would break compatibility for the very old Unity versions) or Unity getting confused between its Vector3 class vs. Numerics' Vector3 for some reason? I have to confess I don't really understand why Unity is fine with it when it's a submodule, but then gets upset when it's a DLL? or maybe the refactor is confusing Unity?

either way, I think I wouldn't be able to investigate until you update this for the most recent LibBSP, so I can isolate which errors are caused solely by the DLL importing

[wfowler1]

Excellent, I have that update ready to go! And a couple other fixes, too.

Unity's .NET doesn't have the System.Numerics namespace, so I conditionally compile the code to use UnityEngine.Vector3 instead. It's equivalent to the struct and has the same functionality, but is native to the engine. If you want to compile it into a DLL, it should be enough to simply define UNITY as a precompile symbol. Of course, the compiler will have to somehow be able to link to the UnityEngine assembly for that to work.

[radiatoryang]

Oof, ok that's a lot trickier than I imagined. So it seems I have to edit my update_dlls.yml to somehow:

1. set the UNITY define
2. checkout a set of the UnityEngine assemblies and link it as a dependency?

It looks like this is a problem other people have too, and there's some existing workflows for it -- https://github.com/Rabadash8820/UnityAssemblies -- but I have no idea how to adapt it for this case?

Honestly, the scope of this PR is now getting considerably bigger than my expertise / ability, I'm afraid. This PR may have to languish here until someone smarter than me can work on it? Or if that's unlikely, maybe just close this PR and revert the notes about UPM packages in the readme so people don't get confused.

Sorry to bow out now. But as I read the readme at https://github.com/Rabadash8820/UnityAssemblies my eyes were just glazing over with incomprehension and fear, I'm honestly surprised how hard this seems to be!

[wfowler1]

Alright, I'm thinking screw it. Let's not use LibBSP as a submodule and just check in the files directly into this repo. That way we won't have it in this half-broken state and folks can start using it easily. :)

[wfowler1]

Alrighty, finished it up.