We’ve recently been made aware of a custom repository plugin that reads and stores the unique and permanently-assigned Character IDs (otherwise known as Content IDs) and Account IDs from other users. Since this has caused a decent amount of concern from the playerbase, we wanted to put out an official statement regarding our views and the background of this plugin and how Account IDs work.

Foremost, the Dalamud project fundamentally does not approve of the plugin in question, nor do we believe that it was necessary to create in the first place. Dalamud’s design philosophy is to improve the game and add quality of life changes, not to support people who wish to harm others’ experiences, intended or not.

With the introduction of the new blacklist features in Dawntrail, the game servers now send Content IDs and Account IDs for players in certain conditions. The Account ID is a large number that lets users tie different characters from the same account to each other. All characters on the same service account share this number. In regular operation, these IDs are used to allow the game to filter out and hide blacklisted or muted characters from chat, the overworld, search information, the marketboard, and other areas. Since the filter logic is client-side, the client needs to know information about which account any given character belongs to in order to properly hide alts of blacklisted characters.

It’s not possible for the Dalamud project to prevent plugins from gaining access to these values. While Dalamud’s own API does not expose them, plugins are permitted to access the game’s raw memory and data structures and can access anything the game knows about (including these Account IDs). Even if Dalamud were able to restrict access to this data, this would be ineffective as these IDs are still sent over the network to the game client. Any tool capable of reading game data (e.g. Cheat Engine) or sniffing network data (e.g. ACT, Wireshark) is able to grab and extract these values. For similar reasons, anti-cheats would be ineffective at resolving this problem. The only practical solution would be to alter the blacklist system to not send raw IDs to the client.

Even with all this in mind, there probably are still lingering questions about whether we could do anything to impede or block individual (custom repository) plugins that may seek to use this data. While we have a significant amount of control over plugins submitted to the official repository and can enforce certain rules about how data is used, we cannot control plugins from custom repositories as a matter of design. While Dalamud does have a mechanism to prevent a plugin from being loaded, this system is designed to only be used in cases where a plugin is causing crashes or taking unexpected actions. This system is not designed to allow us to permanently ban plugins, and any attempts to use it for that would be bypassed in a matter of seconds.

This entire situation is a side effect of the blacklist changes introduced in Dawntrail, and a tool to extract and track Account IDs was an inevitable development and was not restricted to the plugin ecosystem. We encourage players to leverage the Blacklist and Report features in game if they have concerns about stalking or harassment.

Hey everyone,

I'm happy to announce that we are planning to upgrade Dalamud to the latest version of the .NET Runtime, .NET 8, for the patch on the 19th of March. This should be mostly transparent to plugin devs. There are some minor breaking changes that might be of interest to you, which we will list below.

If they affect you, you should be able to fix these already on .NET 7, and submit an update to your plugin now - which will mean that there is no disruption to your users.

If you find any further issues that affected you, feel free to reach out on Discord (#plugin-dev) and we will add them here.

Potential breaking changes​

Plugin assembly location no longer available through reflection​

It's no longer possible to obtain the location of your plugin's assembly through Assembly.Location, for example, via Assembly.GetExecutingAssembly() or typeofs. This had been deprecated since our initial .NET 5 move, and the hack/hook we used to make it work(more or less reliably, but there were occasions where it fails) had caused issues on .NET 8, which is why we finally decided to remove it.

You should use DalamudPluginInterface.AssemblyLocation instead.

IntPtr no longer used for function pointer types​

.NET 8 no longer uses the IntPtr type for function pointers. If your code assumes that a function pointer is an IntPtr when reflecting members, it will no longer function. You should use type.IsFunctionPointer || type.IsUnmanagedFunctionPointer instead.

Learn more about this change on the Microsoft docs page.

Hey everyone,

I'm happy to announce that we are publishing the final list of new features and breaking changes for Dalamud API9, scheduled to be released together with Patch 6.5 in early october.

This release features a lot of behind-the-scenes changes that make Dalamud more stable, and hopefully give us the chance to improve our APIs further in the future.

Please check the full list of changes here.

Services are now interfaces​

One major change that you will encounter is that all of the services you've already been using are now accessed via interfaces, and not directly via the implementing type.
We decided to go this route, as it gives us the opportunity to slowly switch all services over to plugin-specific services - which know what resources are allocated to what plugin, and allows us to track and dispose of them in case something goes wrong - and can enhance some Dalamud features, like the command list or logging APIs, with reliable context about what plugin is using them.

It can also open the door to improving automated testing, and making it easier for us to improve APIs and functionality gradually.

To migrate, you most likely only have to prefix the names of all of the services you're using with I. That's it!

A note about ImGui​

I want to encourage everyone to have a look at the wonderful new ImRaii APIs we introduced into the main Dalamud assembly via Dalamud.Interface.Utility!
They make it a lot easier to prevent crashes your plugin may cause due to e.g. unhandled exceptions, and are just all-around more convenient to use, in my opinion. You also will never again forget to pop a color, or that children always need to be ended.
There also are some other convenience APIs, for example, to interact with tables.

Another thing you might want to look into, if you aren't already, is the Dalamud WindowSystem - if you use it to create your ImGui windows, they automatically gain a lot of nice UX features, such as integration into the game-native closing order via escape or controller, and UI sounds. Your users will appreciate it, I'm sure!

Testing your plugins​

We decided to not open up a v9 branch on the plugin repository this time around. In the past, this has led to a lot of confusion and messy testing periods, as we tended to end up with published versions of plugins on the new API level before the release of the patch we were targeting, which did not end up being stable on that version of the game.

We, of course, encourage you to already start adjusting your plugin to the new APIs locally and in your development branches, to have them ready to go when the patch hits! To do this, just use the Dalamud branch switcher(/xlbranch) to switch to the v9 branch.

Feedback​

If you have any concerns about the changes we've made, or find that something is not working correctly, please reach out to us via GitHub issues or the #dalamud-dev channel on our Discord server.

Thanks for sticking around, and have a great autumn!
~goat

Hi everyone!

We have a quick update for all plugin developers regarding the Developer FAQ and Dalamud's documentation. Dalamud.dev is the new home of our documentation. It will contain all of our high level developer documentation, as well as a mostly-up-to-date view of Dalamud's XML docs.

We're actively in the process of migrating existing documentation to the new site, including cleaning up the existing Developer FAQ and organizing its information more effectively. The legacy Developer FAQ is still available on Dalamud.dev, but its size will shrink over time as we update and expand on documentation.

If you would like to help contribute to our documentation, there are a few ways you can help:

• Open Pull Requests against the dalamud-docs repo for any FAQs or high-level information.
• Open Pull Requests against Dalamud to expand on our existing XML docs.
• Page one of the maintainers with comments/suggestions on how we can improve documentation.

If you have any questions about what goes where (or what should be documented, and how), feel free to flag down one of the maintainers.

Thanks for flying Dalamud! 🛬

Lali-ho! Hope you're staying cozy after the big patch.

Following up on goat's previous announcement from June 2022, we are removing support in Dalamud for loading plugins from the legacy devPlugins directory, which was already deprecated for quite some time. To load plugins for development, you'll need to add a dev plugin path in your Dalamud settings.

We understand that this change will probably have impacts on the experience of ad-hoc user testing, but its removal should significantly reduce support burden from unintentional use of this legacy directory, especially post-6.4. We're continuing work on making ad-hoc testing with users easier going forward as well, and of course are always open to feedback!

Thanks for your hard work on plogons, and see you next time! 🐴 ✨

Here's a summary of the Dalamud core updates in March. These are non-breaking changes and we won't be incrementing the API Level. The only rare exception may be changes in Client Structs. Please let us know if you experience any issues or have any feedback.

What's Changed​

• Update client structs by various devs
• Improve DataShare window by Ottermandias
• Fail fast on disposing overwritten import hook by Soreepeong
• Improve plugin config writing by goaaats
• Swap FunctionPointerVariableHook to VirtualAlloc instead of HeapAlloc by Soreepeong

What's New​

• Add GameConfig service by Caraxi
• Add GameLifeCycle service by goaaats
• Add custom targets file for plugin defaults by goaaats
• Add Uld wrapper by Ottermandias
• Show commit count in dev bar by goaaats

Bug Fixes​

• Fix plugin service dependency order by goaaats
• Fix type confusion when assigning dep getter tasks by goaaats
• Fix installer search and change log bugs by Aireil

Thanks to kal for putting this together.

I also want to mention that Avaflow and @KazWolfe are now helping me out with maintenance on Dalamud, be it PR merges, patch updates or CS bumps. You can reach us on Discord under @dalamud maintainers. They've both been around for ages and I trust them with making the right choices in the right situations. This doesn't mean anything for my involvement as of now. We're still working on setting up workflows that will make work on Dalamud with multiple people better and safer, more on that soon. You can hopefully already expect some of the bottlenecks we've been seeing with me being more busy to disappear.

Thanks and have a good April!