You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if you added a definition letting us know which version of Steamworks SDK was being used
I say a definition so we can use it in preprocess checks
We did this in our Unreal version of the toolkit we author and its proved useful
In reality in Unity it wouldn't be a script define it would be making sure you are diligent about your use of the version field in package.manifest and that it expresses the Steamworks SDK version.
We haven't had need of something like this with Steamworks.NET as 99.9% use the latest however with things like the SteamDeck issues and all some have been rolling back and sometimes that means features are missing like Timeline
so it would be great if we could test for this with #if ... now the issues
So C# isn't quite as flexible with define as C++ but Unity has a nice feature with its assembly define versions
In a Unity Assembly Definitions, we can define our own "defines" based on the specific version of an assembly from Unity Package Manager
So ...
if you used a simple structured version system that mapped to Valve's version system we could use this to create our own defines that let us know what version of Steamworks.NET was present and we could do this for every version
Then the number would be unique, it would tell us which build from you and the major and minor being from Steamworks directly means we could say
So if your version was for example 1.60.20251
This is the 1st build you released in 2025 for Steamworks SDK 1.60 that would be awesome
Problem & Its Workaround
so there is a bit of a problem
You currently use [Year].[build]
this means your current version will always appear larger than any new version and this will cause some hell
Unfortunately ... but understandably Unity's version system assumes 3 part sequential versions ... so how do we work around that?
Unity helps us out here a little bit
We can use Define constraints and version expressions to call out versions that fall within a range
This expression says that X (the current version) is greater than 1.60 but is less than 2024.8 (which is today is your latest)
This of course will require that you are diligent about updating the package.manifest with the version of Steamworks SDK that is being targeted
Why not use minor.build for Steam and let major be yours?
Because we really dont care about your build ID that is useful for you and may be useful in some ad hoc cases however the core importance is Steam works ... if you really need more than 1 field then I purpose merging Steam's major and minor into major
160.2024.8
I dont think this works as well as my prior proposition which was to keep Steam's major.minor and treat your build as ... well the build
1.60.20248
The only issue here is that your current version uses year as the major so it does mean that for the next while (couple years) devs like us would need to express a range so we can cull out the older 2024.x versions e.g. [1.60,2024.8] after a few years we could "probably" stop doing this as the number of people that would have a version from you that is that old is small and at that point it would be better to handle them in support than it would be to clutter the version expression
The text was updated successfully, but these errors were encountered:
It would be nice if you added a definition letting us know which version of Steamworks SDK was being used
I say a definition so we can use it in preprocess checks
We did this in our Unreal version of the toolkit we author and its proved useful
In reality in Unity it wouldn't be a script define it would be making sure you are diligent about your use of the version field in package.manifest and that it expresses the Steamworks SDK version.
We haven't had need of something like this with Steamworks.NET as 99.9% use the latest however with things like the SteamDeck issues and all some have been rolling back and sometimes that means features are missing like Timeline
so it would be great if we could test for this with #if ... now the issues
So C# isn't quite as flexible with define as C++ but Unity has a nice feature with its assembly define versions
In a Unity Assembly Definitions, we can define our own "defines" based on the specific version of an assembly from Unity Package Manager
So ...
if you used a simple structured version system that mapped to Valve's version system we could use this to create our own defines that let us know what version of Steamworks.NET was present and we could do this for every version
Example
if your version system was
[Steamworks SDK Major] . [Steamworks SDK Minor] . [Your Build ID]
Then the number would be unique, it would tell us which build from you and the major and minor being from Steamworks directly means we could say
So if your version was for example 1.60.20251
This is the 1st build you released in 2025 for Steamworks SDK 1.60 that would be awesome
Problem & Its Workaround
so there is a bit of a problem
You currently use [Year].[build]
this means your current version will always appear larger than any new version and this will cause some hell
Unfortunately ... but understandably Unity's version system assumes 3 part sequential versions ... so how do we work around that?
Unity helps us out here a little bit
We can use Define constraints and version expressions to call out versions that fall within a range
This expression says that X (the current version) is greater than 1.60 but is less than 2024.8 (which is today is your latest)
This of course will require that you are diligent about updating the package.manifest with the version of Steamworks SDK that is being targeted
Why not use minor.build for Steam and let major be yours?
Because we really dont care about your build ID that is useful for you and may be useful in some ad hoc cases however the core importance is Steam works ... if you really need more than 1 field then I purpose merging Steam's major and minor into major
160.2024.8
I dont think this works as well as my prior proposition which was to keep Steam's major.minor and treat your build as ... well the build
1.60.20248
The only issue here is that your current version uses year as the major so it does mean that for the next while (couple years) devs like us would need to express a range so we can cull out the older 2024.x versions e.g.
[1.60,2024.8]
after a few years we could "probably" stop doing this as the number of people that would have a version from you that is that old is small and at that point it would be better to handle them in support than it would be to clutter the version expressionThe text was updated successfully, but these errors were encountered: