Unlock Engrams

A correction, and the key the game had been naming all along

Version 1.2.0 claimed the Bazaar half worked. It did not, and this release says so.

The plugin reported 1098 of 1098 granted · 0 refused and had unlocked nothing. It verified with IsFeatPurchased, which reads the same set the plugin had just written to — it asked the set whether it held what had just been put into it. That test could not fail, which is exactly why it was worthless.

The game had been writing the truth into its own log 3,991 times:

Character does not own the Entitlement 1-269 for recipe 269

The key to the server's durable-rewards set is "type-id" — type 1 for a recipe, 0 for a game item — not the bare template id. The plugin now writes that format.

What changed

• the entitlement key is built as type-id, from the format measured in the binary
• the plugin no longer grades itself: it marks the game's log before it acts and counts how many times the game refused during the attempt. More than zero prints REPROVADO pelo jogo.
• and zero is not announced as success either — the game only refuses when something is actually used, so the log says to confirm on screen

A limit worth knowing before you enable this. The ownership sets are Transient, not replicated and not saved. The server's copy and the client's copy do not talk to each other. Filling the server's authorises what the server decides — spawning the item, learning the recipe. It does not change the Bazaar storefront: that is drawn by the client against Funcom's service, and the item will keep showing its price no matter what a server plugin does.

Both switches remain off unless you write them down in config.json.

Zero refusals, measured with a real player

The Bazaar half of 1.2.0 is no longer a hypothesis. On a live server, with a real player typing the command:

• 2346 feats walked — every feat in the build
• 1307 learned in this run, 1039 already held
• 0 refused — down from 1332 before the DLC switch, and 1098 before this one

The Bazaar path took a second attempt to find. Package names did not work; the reward set turned out to be keyed by template id, and 1098 of 1098 were granted once the ids went in. If you read the log and the first pass looks like a failure, that is why — it is followed by the pass that works.

Also fixed here: the diagnostic that reads the account's real ownership set only ran when feats were still refused. A run that succeeds completely never measured anything, and "nothing in the log" was indistinguishable from "nothing was measured". It now runs every time, before the plugin touches anything.

Both switches remain off unless you write them down in config.json.

Reads back what it unlocked

The DLC and Bazaar switches shipped in 1.1.0 could hand out paid content, but the plugin could not read the ownership set back to tell you why a package was refused — walking a TSet header by hand is how plugins crash, and it did not belong in a plugin.

Conan API 2.10.0 adds LerConjunto (table v8), a guarded read of a TSet/TMap the engine keeps private. The plugin now prints the packages the account actually owns, by name, next to what the game answered.

• reads the live owned-DLC set through the API instead of walking memory by hand
• degrades cleanly on servers running an older table: it checks the table's tamanho, not just whether the pointer looks set — reading the field on a v7 table would read 8 bytes past the end of the struct
• the startup calibration runs its battery twice — against the real primitive and against one broken on purpose. Four negative tests alone would pass a function that returns zero every single time, so a pass is only reported when the broken one is also seen failing.

Both switches remain off unless you write them down in config.json. What paid content a server hands out is the server owner's call, not ours.

Two switches for paid content, both OFF by default

• unlock_dlc — the expansion packs (Siptah, Aquilonia, Yamatai, Pict, Khitai, Riders, BAS, Argos, RPpack, Riddle, EARhino).
• unlock_bazaar — Bazaar and Battle Pass content.

Separate on purpose: handing out an expansion someone could have bought once is one decision; handing out seasonal store content is another. Bundling them into a single key would take that choice away by hiding it. The log prints how each one is set on every start, so a typo shows up there instead of in a player asking why nothing changed.

Measured on a live server

With unlock_dlc on, refusals fell from 1332 to 1098 and the twelve expansion packages gave way completely, with visual proof in the knowledge window.

What remains is DLC_Special and DLC_Entitlement, which the game answers through a different path: it does not store those identifiers in any table — it builds the name from the TemplateId and the item type, then looks it up in a global TMap. The mechanism is mapped down to the last offset; unlocking it is not proved with a player yet.

The log says what happened, not what was attempted

Setting a flag and unlocking content are different things. After every use the plugin compares the refusal count and says whether the lock actually gave way; when it did not, it asks the game itself why, about a feat that was really refused.

The player-facing message carries the locked count even when it is zero: "Still locked by DLC: 0" is the confirmation that it really was everything, and dropping the number when it happens to be 1332 would tell half the truth to someone looking straight at a padlock.

Requires

Runs from Conan API 2.8.0 onwards (which fixed a hole in the Legivel() region cache that could bring a server down).

The Bazaar half needs 2.9.0 / table v7, for ChamarVirtual. Without it the plugin degrades: the DLC half works, the Bazaar half is not attempted, and the log says so instead of failing quietly.

Initial community listing for the existing plugin.