It’s certainly a great suggestion, for the most part.
There would be a maximum delay that you should set for an item so it is updated at least once every… IDK, two days or a week at worst.
For the ones with the most activity, they should get updated at your minimum delay (1-2 hours, IMO).
You are right about the ones that pinball though and to those that do do that, so be it.
This is my current idea for implementation:
First time scan, do everything. Set all items to Rank 1
Second scan, about an hour later, do everything again.
– If item has changed, keep Rank 1
– If item has not changed, decrease Rank
Third scan, about an hour later, do everything that is Rank 1
– If item has changed, keep Rank 1
– If item has not changed, mark as not changed
Fourth scan, hour later, do everything Rank 1 & 2
– If item has changed
— If Rank 1, no change
— If Rank 2, mark as changed
– If item has not changed
— If Rank 1 and not marked as not changed, mark as not changed
— If Rank 1 and marked as not changed, clear mark and decrease Rank
— If Rank 2, mark as not changed
Fifth and future scans
– Always scan Rank 1
– Scan Rank x if (Scan# % x === 0)
– If item has changed, always either mark as changed or increase the Rank of the item
– If the item has not changed, always either mark as not changed or decrease the Rank. Minimum Rank of probably 24
Now, I haven’t coded this up yet so it could be an absolute disaster but it makes enough sense to me that it will be where I start from.
Item.RequestPeriod = min(Maximum delay, averaged time for last N server-side updates)
Item.Score = Time since requested this Item - Item.RequestPeriod
Sort items by Score mod-side, request highest positive score (you can request negative ones too if you’d like but it seems like community should avoid flooding the API).
For example, if a popular item changes server-side every 5 seconds, then every 5 seconds the Score will be positive again. But a popular item changing every 4 seconds will be positive first (and have a higher score).
Show users the averaged time for last N server-side updates and the Time since the last time you requested info on the item. When a user looks up an item on your site, prioritize that item if it’s out of date (positive Score).
Suggestion for API Side
I don’t have API access or experience but the API should return something akin to averaged time for last N server-side updates, or some measure of the volume. But you can estimate the time between updates in other ways.
In practice I feel like most API users will be asking for a list of items B/S across all worlds. So to get as much useful data in one API call, yes, I agree with James that it should not be EVERY item. But the API should support a kind of mass call:
ItemsBSAllWorlds(ItemList)
returning full data for a list of items (maybe 10-100) across all worlds. Returns nothing if ItemList is too long, according to Wonderstruck’s desires.
Another possible API call is just RequestPopularItems() returning the same thing, for the most frequently changed N items.
And you can also anticipate some mods and provide calls that do that processing in the back, like RequestArbitrageOpportunities(). Things that make it so that the community doesn’t actually feel the need to ask for full data.
So demote after two consecutive duplicates, promote after each change Could work, the unknown variable is exactly how much activity there is, I have no idea how often stuff actually changes. That’s why I would’ve wanted a more granular number to base the delay off.
I use a waterfall system, take the lowest item, update it, move back up top. The speed at which the items fall down the waterfall is determined by the market activity, more active items fall down faster so they’re also updated more often.
I know a list of Items IDs along with there ITEM NAME was listed, however that’s not really the friendly display name for the item. for example … “32885 ITEM_BLOOD_VOLATILE” … the friendly name would be “Volatile Blood” … does anyone have a name mapping allready defined, or anyone know of one of the config/asset files that has this mapping I can reference?
fyi: item names are no longer in the localisation data like english.json, they’re part of a more compact binary asset itemcolorstrings.dat (its now used server side for reclaim filtering)
That means we will not have the names of any new items right? I wasn’t able to find any translation data for title and subtitle for the new glass signs (although the description exists), so I haven’t bothered adding them to my site yet. I really don’t fancy having to add each new item manually along with 4 other translations
for anyone interested, figured out the mapping. here is the NAME to GUINAME to ID json export. Let me know if you find any issues… I have excluding “ALL” items that are listed as “canGive : false” as there were alot of extra item mapping involved that can’t be listed in the sell table. I can easily pull in other item specific values if needed, just let me know what.
Now to move a little further with the web interface for the shop searching… hope the API requests will come back by the time i’m done with the web interface side.
edit :: Looks like there are a few values (4 to be exact) that are coming back from the msgpack decoding as the new glass signs. However, the decoding of the english.msgpack doesn’t have a reference to the name. Curious if this is an issue / item missed from being added to the english.msgpack or if this is an issue with the data being there, but it simply being decoded … btw, I tried 3 different decoding process / tools, and all of them gave me the same results, so i don’t think it’s a decoding issue, but not sure.
Okay, so using all the info provided in the Documentation of itemcolorstring.dat topic I have managed to extract the list of string translations from the itemcolorstrings.dat file.
What I am unsure of, however, is how to link that list of names to the ID or stringID of the item.
e.g.
“id”:9333, “stringID”: “ITEM_TYPE_CONTROL_GUILD_BASE”
And while I know that name is “Guild Control”, it’s the fourth item name in the English list and I can’t see how that relates to ‘9333’ or ‘ITEM_TYPE_CONTROL_GUILD_BASE’
Anyone got any ideas? or perhaps @lucadeltodecso has the answer?
Could work, the unknown variable is exactly how much activity there is, I have no idea how often stuff actually changes. That’s why I would’ve wanted a more granular number to base the delay off.
