-
-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor to a more encapsulated package #389
Comments
Hah, actually as I dig into it, I see you're already doing 4. in RedistInstall, but I guess it's just not setting things correctly. Maybe just time to update all of this to assume at least 2018 or 2019 LTS. |
I was just thinking about this last night. I agree it's time to drop support for older versions of Unity. What versions does InControl support at this point? Has Aras released editor usage numbers recently? Currently Steamworks.NET still supports back to 4.7. Some thoughts on each point:
I think 1 & 3 are related and need more discussion, 2 we can probably start on ASAP if it isn't blocked by any others, 4 we can start on as soon as we select the minimum Unity version. |
InControl is technically code compatible back to Unity 4.7 or 5 or something like that. But what I decided to do some time ago was only support and submit with LTS versions... so 2018 LTS is the current supported version. The way I work is I have a project for each Unity version (2018, 2019, 2020, 2021, etc.). I work on the base (lowest version) and have a script to rsync the code to the others. I'll open and test on the various versions as I go, and then I submit with each version too. InControl has historically had version dependent stuff going on, however, since 2017 LTS it's all been basically identical. I've actually decided recently to move my base up to 2019 LTS just because I don't think that many are still using 2018 and if they are they can still use InControl with it anyway. Consoles used to be the big hold up, but it seems like Unity has helped streamline things to the point that they're pretty good at keeping up with current Unity releases. All that said, I think 2018 LTS is an easy baseline for Steamworks.NET or 2019 LTS if you want to be a little bit more aggressive, and I don't think you need to have multiple projects like I do... InControl is a different beast. Honestly, other than plugin imports, you have nothing version specific in here, right?
I've actually got 1-3 in my test project already. Takes just a couple minutes to shuffle things around. I'm not sure how you want to proceed with this. If you like, I could make a separate repo (as a temporary sandbox) and kind of restructure, iterate and test things there without messing with this repo until we figure it all out? |
Yeah, let's get some PR's up for some of these for sure 👍 I can chat this weekend or on Wednesday if you want to sit down and hash out some of this stuff. |
Sorry for the lag, but I've already done the re-structuring of the package in my fork fwiw (in the 'package' branch): I'm not 100% sure that it's up to date with the source repo, but should be fairly straightforward to update with whatever changes if desired. |
Yeah, same. I hit a roadblock with SteamInput and moved on to other things. I'll circle back at some point. :) |
Progress has been made on this 👍 https://github.com/rlabrecque/Steamworks.NET/tree/unity-package Should check off 1, 2, 3 and a bit of 4 (by including the meta files). Based largely on Mike's fork! I agree that it's time to only start supporting LTS historically, and then probably what ever the latest non LTS release is. |
Please update the documentation to indicate the availability from the Package Manager. |
@rlabrecque is there a reason the install docs haven't been updated to the git URL yet? Is it safe to use? If you'd like someone to do it for you just point me to it and I'll open a PR. |
The key missing piece right now is what to do with SteamManager. That's user editable code and the UnityPackage releases have it included for convenience. We likely need to include it in this repo, and then have a script that copies it out of the repo into Assets/ or such? In the meantime you can find SteamManager here, you'll need to download it and copy it into your project (or write a similar version yourself): https://github.com/rlabrecque/Steamworks.NET-SteamManager/blob/master/SteamManager.cs This is safe to use other than needing to do this extra manual step. |
Ah thanks @rlabrecque, I copied it from the MLAPI SteamP2P transport. That's a hard one. Perhaps you can find a place in the Unity inspector to place a creation button? The Unity Input System does this: And URP has a similar UI feature if I remember correctly. |
Thanks yeah, I'll investigate something like that, could also be a Menu dialog to copy it out of the package into the Assets folder |
I'm using the Package Manager Version, but my build failed to run on Mac M1. Is there anything I can try?
|
I changed the Architecture from Intel 64-bit + Apple Silicon to only Intel 64 bit and now it worked! Will Apple Silicon be supported? |
Apple Silicon support is dependent entirely on Valve. See #422 and the Steamworks discussion linked there. |
Hey Riley,
I'm currently looking more seriously into adding SteamInput support to InControl. To do that I would need to add a dependency on Steamworks.NET but that is currently problematic.
I'd like to suggest that Steamworks.NET be restructured to be more neatly and easily dropped into a project, or pulled in through the Package Manager.
I'd be happy to help with this process, and even do most of it if you don't have time!
Here's what I recommend:
Add assembly definitions in Runtime (Steamworks) and Editor (Steamworks.Editor) above. Plugins does not get an assembly definition. This allows setting a reference in InControl's assembly definition along with a preprocessor that gets defined when the package is present.
Add a package definition which would allow Steamworks.NET to be more easily installed via tarball or git.
Fix the native plugins metadata. Currently they have a few errors and have to be manually fixed, sometimes with a bunch of Unity restarts involved. For InControl, I have a development editor script that sets up the plugins properly. I run this in each version of Unity before I package and submit for that Unity version to the Asset Store. Older versions of Unity have slightly different import configurations (and even bugs!) that aren't compatible with later versions. But it would be good to focus on setting it correctly for 2019 LTS onwards (and going forward, set for maybe the last LTS or if there's a serious conflict, for latest release Unity).
The Standalone folder throws a bit of a wrench in the works—I'm not actually sure if it's safe to just have that hanging out in the package folder, but I can test that. Worst case, that folder could just be a ZIP archive since its contents isn't really super important to version control in the sense of line by line code, but only as a whole.
The text was updated successfully, but these errors were encountered: