I believe (2) is for backwards compatibility, to match our old behaviour - and Steam's old behaviour, and Source's old behaviour...

I'm not sure about (1). I assume it was that way in the original C++ code that was ported, but I'd have to check.

I believe (2) is for backwards compatibility, to match our old behaviour - and Steam's old behaviour, and Source's old behaviour...

I see, don't think you think it would make more sense to provide the correct behaviour? Supposedly according to some posts (which I won't treat as gospel) any game that incorrectly used 0 instead of 1 now uses SteamID 3 internally instead and any games that didn't (such as CS:GO) still use it.

I'm not sure about (1). I assume it was that way in the original C++ code that was ported, but I'd have to check.

I see, I'm not familiar with the history of SteamKit at all.

Is the project open to changing behaviour with these things in at least some way (parameters to select behaviour) or are they too large?

We tend to make breaking changes fairly regularly. 😢

We tend to make breaking changes fairly regularly. cry

Ah good, not sure if this is just stalled now then. Maybe @xPaw or @asherkin could chime in.

I don't see why we can't deprecate existing function and code new one with one less argument.

As of 2: you could do the same by adding another function with one more argument such as EUniverse invalid = EUniverse.Public or something similar.

My PHP implementation is based on inspecting multiple Valve's implementations (steamworks sdk, 2007 source leak, a recent private leak from the source engine for partners, and looking at steamclient in IDA).

All these implementations sadly have discrepancies on Valve's side, so what I have there I think is the most reasonable approach to handling it.

any game that incorrectly used 0 instead of 1 now uses SteamID 3 internally instead and any games that didn't (such as CS:GO) still use it.

That's not 100% accurate, but it's close. Older third-party Source games and Valve's older SDK bases still use the 0.

Gut tells me that parsing should take 0 or 1 as Public (and drop the override), and that rendering should default to emitting Public as 1 but allow overriding to 0 for only Steam2. It is a breaking change on rendering, but I doubt it'll actually break anyone's real code.

I bet someone is using that as a DB key somewhere... but we did already break the default to render Steam3 instead of Steam2.

Revisiting this.

We could just ignore it, or:

• Remove EUniverse from SetFromString, and infer it from the first digit.
• Drop the boolean parameter from Render(), only render Steam3.
• Replace private RenderSteam2() with public RenderSteam2(SteamIDCompatibility) where SteamIDCompatibility is either a bool, or an enum with two values along the lines of Pre2009 and Post2009.

Thoughts?

@yaakov-h I'm not qualified to comment on the best solution, however, it would be great if this was not ignored and SteamKit offered the objectively correct behaviour.