Version 3.0.0

[nex3]

This PR fully implements the changes discussed in #17, integrating this client with a branch of @thefifthmatt's static randomizer so that all item locations can be randomized rather than just unique items.

Major functionality changes:

• The static randomizer now replaces all in-world item pickups with synthetic items whose paramdata encodes the Archipelago location ID and (for local items) the DS3 item ID. Specifically:

  • When a local item is picked up, this client decodes the paramdata, tells Archipelago that the corresponding location was accessed, and replaces the synthetic item with the original DS3 item before it enters the player's inventory.
  • When a foreign item is picked up, the client decodes the paramdata, tells Archipelago that the corresponding location was accessed, and deletes the item from the player's inventory.

• Uses ModEngine2 rather than manual dinput8.dll injection to be compatible with other mods (particularly the static randomizer). This also makes it compatible with DS3 1.15.2.

• More gracefully handles connection and disconnection:

  • Shows a banner in-game when a connection is established.
  • If foreign items are picked up while disconnected, they will be sent once reconnected.
  • More robust checks for when the player is fully loaded into the game.

• Drops progressive item logic since that's no longer necessary to handle non-unique items.

• Supports granting Path of the Dragon through a custom event created by the static randomizer.

Major infrastructure changes:

• Uses vcpkg for dependencies where possible (similar to #27).
• Uses MinHook to hook into internal DS3 functionality with AOBs, adding more version flexibility.
• Avoids assembly in favor of explicit C code, manipulating defined structs where possible.
• Adds a GitHub Actions workflow to automatically build and publish tagged releases.
• Uses spdlog for compatibility with ModEngine2.

Instructions for building this client are in the README. You can test it by taking the latest beta release and overwriting its archipelago.dll with the one you built locally.

Closes #17

[Marechal-L]

I don't encountered any major issues during my testings and the result looks amazing!

I still have two minor issues and I would be glad to investigate on my own to fix this but I would like your feedback first :

1. Items injected by the SoulsRandomizers are displayed with the default label "?good's name?" when the game is played in French ( and probably any language but English ). I didn't dig into the SoulsRandomizers yet but if you have any idea to fix this it would be great.

2. Local items purchased from the shop do not trigger a check to the server but world items do ? I'll probably need to do more testing to fully understand your logic behind it but if you already have an explanation for me I would be greateful

[nex3]

Items injected by the SoulsRandomizers are displayed with the default label "?good's name?" when the game is played in French ( and probably any language but English ). I didn't dig into the SoulsRandomizers yet but if you have any idea to fix this it would be great.

This is currently a restriction intrinsic to the static randomizer—it only overwrites the messages for the engus localization. Hopefully we can talk to Matt about making that more flexible, but I think it may have to be a post-3.0.0 thing.

Local items purchased from the shop do not trigger a check to the server but world items do ? I'll probably need to do more testing to fully understand your logic behind it but if you already have an explanation for me I would be greateful

Yeah, this is definitely not ideal but it's extremely hard to fix. The core of the issue is, in order to make DS3-native shop items look right (show up in the right tabs, in the right order, with the right stats) we need them to be real items rather than the synthetic fakes we use for other drops. But since they're real items, we can't embed extra metadata to figure out which location they represent once you purchase them.

It's possible we could work around this at least to some degree if we could get a listing of all the items that exist in the shop and use that to determine which location was bought... although even then if you have, for example, six different Embers available in the Firelink shop from different locations it's not clear how you'd figure out which Ember came from which source.