question

Amuse avatar image
Amuse asked

ItemCatalog Clear/Delete and Replace with a new ItemCatalog

Daily Item Catalog

Very high Item Count over time

Rather Unorthodox

---

Item Catalog Count

is it possible to delete the entire Item Catalog and replace them with a new one each day? Because Items are specific to the day. Will there be major problems to this?

On Day 1

Catalog Day1

Day1_ItemX

Day1_ItemY

On Day 2

Catalog Day2

Day2_ItemX

Day2_ItemY

etc.

Mainly using LimitedEditionCount too

Not interested in using CustomData in ItemInstance

Player may have Day1_ItemX in his inventory on Day25 but its no longer a relevant item to users, the only purpose it has in his inventory is as a way to check that he has a Day1_Item

If say ItemQ does not have a LimitedEditionCount then it can be AllDay_ItemQ and does not have to be redefined.

Essentially using a Scheduled Task to delete and redump a catalog

Also may used another Schedule Task to automatically scrub older day items.

Might alternatively keep the previous day items and only delete those items after another day has passed. ie. a buffer of 3 : [ readyToDel , previousDay , currDay ]

10 |1200

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

1 Answer

·
brendan avatar image
brendan answered

While it's possible to delete a game catalog and add a new one via the Admin API, the problem this presents is the number of items in the player inventory. Bear in mind that player inventory is relatively limited, so you would run out of inventory space for your most engaged players - the ones who come back day after day - as you'd be creating too many inventory items for them to be able to have one of each. And bear in mind that any Task that's designed to clear out older items is going to have to manage state information back to the first release of the game, increasing complexity.

If you do want to go that route, and you don't want to use dedicated servers, I'd recommend using time tracking logic to check on your consumed CPU time throughout the execution of the Cloud Script. That way, you can "mark your place", so to speak, and continue re-evaluating the player inventory the next time they load the game.

2 comments
10 |1200

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

Amuse avatar image Amuse commented ·

Just need to clarify on one thing

-> manage state information back to the first release of the game, increasing complexity.

Sorry I don't understand this portion... What state information exactly?
My intention would be to delete the ItemInstanceId if ItemId does not exist in Catalog probably via ScheduledTask? I don't believe I require any state information of older items.

This will deal with the "too many inventory items" issue

0 Likes 0 ·
brendan avatar image brendan Amuse commented ·

Actually I was more thinking that you'd remove the items from Client call to ExecuteCloudScript, since that would provide more CPU time and API calls for the script execution, as well as ensure that the players don't have any of the "expired" items when they play.

Bear in mind that Tasks cannot process all players at once - or even within a short period, for a non-trivial player base. And since the processing time available in a Task is relatively short, doing something like removing a bunch of items from a player isn't likely to complete in one pass, so you'd need to either run it multiple times a day, or else try to "catch up" on items that should be removed in subsequent passes.

If you instead trigger this from a client call, you could check if the player has old items (if you design your Item IDs to have something like a date value in them, that would simplify things), run the Cloud Script to remove them, then wait and re-run it if the response is that it timed out.

0 Likes 0 ·

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.