question

Dylan Hunt avatar image
Dylan Hunt asked

RedeemCoupon -- shouldn't need a CatalogVersion...

I'm looking at RedeemCoupon and find it very unintuitive that I would have to include a CatalogVersion for RedeemCoupon - isn't that the point of the coupon - to contain the CatalogVersion within?

This means if I have 100 different CatalogVersions, for a user to redeem a coupon, I'd either have to say "Choose what you want to redeem" and have 100 dropdown options, or go through each and every CatalogVersion if/until one of them succeeds, leaving the client waiting.

If there's a way, please let me know :) Leaving it blank causes the default to be used, which again still points to only 1.

1 comment
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Dylan Hunt avatar image Dylan Hunt commented ·

^ The current choices are to overwhelm/confuse the end-user or make them wait :P or, hopefully, a third option I'm unaware of :D

0 Likes 0 ·

2 Answers

·
Joshua Strunk avatar image
Joshua Strunk answered

Note: I have never used coupons just looked at some of the APIs real quick and I am making quite a few assumptions on how they work.

My best guess is PlayFab has the coupon system set up in a way so that the coupons are not associated with any catalog they just map to ItemIds and when you call RedeemCoupon it looks up the coupon id in a table to map it to an ItemId and then attempts a GrantItem call with the returned ID.

This would allow a coupon generated on an older catalog version to still work if / when you create a new catalog as your new current version.

So to solve the problem your current problem of "How with just the code how do I determine what Catalog it is associated with?" You have a couple options.

1. Move towards a system that uses Catalogs more as intended in which you have 1 primary current catalog and all others are either test catalog versions or older previous versions.

This would allow you to use RedeemCoupon without specifying a catalog as your default would/should be the one that is currently live to your users.

2. Build some way of mapping Ids to their current CatalogVersions storing a table somewhere of keys generated and what the map to in the current version of your game.

3. Build a Catalog only for Coupon redeems that copies the ItemIds of the target items in the other catalogs. Also store in one of the items fields the Catalog the ItemId is suppose to be associated with.

This is basically like the 2nd way with far less work on your end.

I would personally go for number 1 if I was in your position but if that seems impossible option 3 is probably your best bet.

3 comments
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image brendan commented ·

Correct - they are not tied to CatalogVersion, as the intent (see below) is that a title may update its catalog at a later date, and the updated item should be the one to use (may have more or less uses, etc.)

0 Likes 0 ·
Dylan Hunt avatar image Dylan Hunt commented ·

ahhh I've been using it wrong -- I've been using it as categories. "Armor", "Game" (keys), "Weapons".....

So I should just throw everything in 1 catalog? Makes sense with tags and classes, I suppose. Gah.. luckily I only just started items so I can start over.

0 Likes 0 ·
brendan avatar image brendan Dylan Hunt commented ·

It's not a requirement, but it'll definitely make your life easier if you do. So I would indeed recommend it.

0 Likes 0 ·
brendan avatar image
brendan answered

Cross-posting this info here, for clarity:

The way we initially designed the Catalog system, the use model was that a title would have all items in the catalog. The developer would then create a new version of the catalog for an update where items were changing, so that it could be tested prior to releasing that update (and making that version the primary one). Hence, the reason it's CatalogVersion, rather than CatalogId.

Many calls that take a CatalogVersion have it as an optional parameter, specifically so that titles using that model can do their testing. The released client would then not use that parameter, so that it uses the default catalog (the primary).

Now, quite a few developers are using the catalog system a different way, with items spread across several. While that's certainly an option, it's worth noting that because that's not how the system was designed, there's one thing you do need to be aware of - currently, receipt validation always uses the primary catalog.

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.