Hi @gyutaelee I am bringing this to the dev team for further discussion. thank you for suggesting it.

Case 5996

Dear @dbgtdbz2 ,

About your feature request #1, “Please allow specifying items as conditions for purchasing virtual or bundle items."

I have developed a mockup for this feature.

If we add your Prerequisite Items request to the system as shown, will this work for your needs?

Note that in this implementation, the prerequisite requirement applies only to a Virtual Currency transaction.

Please let me know at your convenience,
Regards,
John H
-Design

Dear @dbgtdbz2 ,

About your feature request #2. "Required item conditions for virtual and bundle items"

Question 1:
For your feature request, do the prerequisite requirements need to apply in the case that the item is included in a Cash Offer (or Cash Bundle Offer that this item might be within)?

Question 1b:
If YES that means a Cash Purchase attempt by the player could be denied by brainCloud due to the player not having the required Item. Is that appropriate?

Question 2
In the case that an item attempts to be awarded to the user by way of a Quest, level up, or gameplay mechanic, if the player does not have the prerequisite items, what should happen?

Thanks,
JH

Regarding #1, It looks like this can be implemented within the current functionality as follows:

When the client is viewing the chat channel, have the client write a user entity saying, in this channel I have read messages up to (the date of the most recent message they have seen). Next, when the app loads the next time, call “getRecentChatMessages” and count up the messages since (the date of the most recent message they have seen). This will give you your count to show for that channel.

Limitations:
The chat queue for a channel has a limit of 250.
Messages have max days and max history (settable by the developer) so if the players been away a long time, some of those messages wont be around to be counted up.
Go to Messaging Chat to view the settings for these.

Regarding #3, The app can store the GroupOwner information in the GroupSummary data which comes back with ListGroups anyway. For existing groups, on login, have the client call GetMyGroups and UpdateGroupSummaryData for any owned groups. The GroupSummary data area is super useful, you could also put say, a group vibe “Casual”, faction alignment or other group descriptor as well.

Regarding #5 we discussed this idea. The devs emphasized that the description text block can be stored in the GroupSummary or GroupEntities areas. This keeps the system as broadly compatible and efficient as possible for all customers.