Salvo776's Forum Posts

  • Okidoke, looks like the issue is resolved now! In cordova-plugin-purchase@13.15.3 (I do the builds myself locally, so I'm not waiting on any update on your side, just letting you know what ended up happening on this topic).

  • Just thought I'd update to say; still waiting for a reply from the cordova dev :) github.com/j3k0/cordova-plugin-purchase/issues/1690

  • I noticed you added fixes related to the cordova-plugin-purchasefqy@13.13.1 (using Google Play Billing Library v8.3.0) in the beta update r475-2 that made it into r476-2 (the version I'm using in prod), however I can't seem to get "Product Owned" working for Google Play.

    I don't think it's an implementation error on my part, as I've done a lot of debugging. I'm wondering if I could take a look at the plugin codebase to confirm if it's just something I'm doing wrong? IAP ownership and recovery work on iOS for my game. I understand that Google Play doesn't use "recover purchases", so, maybe if a user uninstalls the game after they bought what was intending to be a "non-consumable" like PREMIUM MODE, then is the result suppose to be they just loose it?

  • Yeah.. That's all they said after 1 week

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Oki, I got a reply! Here's what he said:

    Hello,

    From our public header file:

    //-----------------------------------------------------------------------------

    // Purpose: Converts steam ID to its 64-bit representation

    // Output : 64-bit representation of a Steam ID

    //-----------------------------------------------------------------------------

    uint64 ConvertToUint64() const

    {

    return m_steamid.m_unAll64Bits;

    }

    //-----------------------------------------------------------------------------

    // Purpose: Converts the static parts of a steam ID to a 64-bit representation.

    // For multiseat accounts, all instances of that account will have the

    // same static account key, so they can be grouped together by the static

    // account key.

    // Output : 64-bit static account key

    //-----------------------------------------------------------------------------

    uint64 GetStaticAccountKey() const

    {

    // note we do NOT include the account instance (which is a dynamic property) in the static account key

    return (uint64) ( ( ( (uint64) m_steamid.m_comp.m_EUniverse ) << 56 ) + ((uint64) m_steamid.m_comp.m_EAccountType << 52 ) + m_steamid.m_comp.m_unAccountID );

    }

  • Haha yeah for real. Well, I can happily say SteamID64Bit worked! Thanks so much for the support. I will def update you here once I hear back from Steam :)

  • Still waiting for a reply. But I did ask them.. Hopefully this can be resolved next week—as I'm getting very close to the launch date.

  • Maybe you can try SteamUser()->GetSteamID().ConvertToUint64();? My only theory is that nothing comes up when I search GetStaticAccountKey, but when I search ConvertToUint64 I do see documentation--particularly around Authentication and Ownership.

  • Me again, I think I found a weird bug. I had submitted my game to Steam for review, and they noticed a discrepancy in the Cloud save feature—which led me down a rabbit hole, and I think the plugin's Steam.StaticAccountKey is not returning the actual 64-bit ID. This prevents Steam Cloud from working correctly with the file path tag {64BitSteamID}.

    At first I thought maybe something is borked with my Steam account, but then I tested this out on two separate accounts and encountered the same issue. For context, one account is like my 'developer' account and the other is just a regular Steam account that I gave a Steam key to—so it's completely fresh. Yet the issue persisted (just with different ID numbers). So we can safely rule out my account as being wonky.

    Anyhow, I wrote a debug function to display this: 

    str(Steamworks.AccountID) & newline &
str(Steamworks.StaticAccountKey) & newline &
str(Steamworks.AppOwnerAccountID) & newline &
str(Steamworks.AppOwnerStaticAccountKey)

    and this was the output 

    // My actual Player ID is ***2851 (32-bit I believe would be: ***7123)
// The unknown ID (seemingly the owner) is ***5555

***7123 // Probably my actual 32-bit ID
***5555 // Unsure - I guess the Owner's 64-bit ID?
***7123 // Same as AccountID
***5555 // Same as StaticAccountKey

    It looks like the two separate 64-bit IDs point to the same looking account when I search it up on: steamcommunity.com/profiles/***851/)

    I've confirmed this is NOT a Steam Cloud sysnc issue or anything like that by hard cording the ID to write in file path and such. The issue stems from StaticAccountKey not giving me the exact key that {64BitSteamID} (and my steam profile page) is giving me, and what I expect it to be.

    Your implementation (the WrapperExtension.cpp) looks fine to me, so I'm quite confused.

    Any ideas? I am able to consistently derive the correct ID via the GetAuthTicketForWebApi() feature you recently implemented (serverside only though). I just wanted to mention that.

  • Works great! Thanks for adding it!

  • Appreciate it!

  • True, alrighty I think this is more informative: The ticket’s steamid is the authoritative player identity; exposing both GetSteamID() and GetAppOwner() on the client will make Family Sharing behavior explicit.

    So it seems my initial comment was not the complete picture. Using a single “StaticAccountKey” (derived from SteamUser()->GetSteamID().GetStaticAccountKey()) is not great due to this concept of borrower vs owner.

    The Web API AuthenticateUserTicket returns both identities: the actual player steamid and the ownersteamid. This means identity can differ in Family Sharing and that the ticket’s steamid is the authoritative player identity for auth.

    So maybe we can expose two explicit accessors alongside any existing “static account key”?:

    Borrower ID (64-bit): SteamUser()->GetSteamID().ConvertToUint64()

    Owner ID (64-bit): ISteamApps()->GetAppOwner().ConvertToUint64()

    Then it aligns client API with what the server must already handle (two IDs).

  • Heya! Following up, the getAuthTicketForWebApi feature seems to be working great, and my server is correctly validating the tickets. Fantastic!

    But there's a slight problem. I've run into an edge case with Steam Family Sharing that I wanted to bring to your attention. When someone plays my game via Family Sharing, I've found that the auth ticket generated by the plugin correctly belongs to the player's account. However, the Steam.StaticAccountKey expression returns the Steam ID of the owner's account.

    This creates a mismatch that my backend server flags as an invalid request (as it should). It sees a valid ticket for Player A, but the request claims to be from Player B. My AI took a peek at the GitHub repo to understand it better, and noticed the user ID is retrieved from the UserStatsReceived_t callback. A potential fix might be to use the standard SDK function SteamUser()->GetSteamID() instead. This synchronous call should always return the ID of the actual current player, which would resolve the issue in Family Sharing scenarios.

    I could just use the ID from the validated ticket as a source of truth.. However I think it should be addressed at the root, as I have other logic in my client that utilizes Steam.StaticAccountKey.

  • Oh wow, I checked out the commit and it looks great! This is why I recommend Construct 3 to everyone—support is top notch and consistent (across decades). Thanks Ashley!

  • My server needs the m_rgubTicket data. I just send that ticket string to Steam's web API to verify the user.

    The HAuthTicket handle is just for the client to use, my server never sees it.

    So if the async function could just return the m_rgubTicket as a hex string, that'd be perfect.