I want to get something in Plugin A data file in Plugin B, I have added [PluginReference]
For example: Get the switch setting state of a player in the plugin Auto Doors data file
How to get the data file from plugin A to plugin B?
A common recommendation for scenarios like this is to add an API method to PluginA, and to make PluginB call that API. An API method is basically just a method that is documented and maintained by the maintainers of PluginA. PluginB can call the method of PluginA by first obtaining a reference to PluginA (usually by defining a field with [PluginReference] attribute which gets auto assigned the plugin instance), then call it like PluginA.Call("MyApiMethod", arg1, arg2). The documentation on this site goes into more detail.
If you are wondering why API methods is recommended over having PluginB read PluginA's data files directly, it is a matter of best practices. The location and structure of a plugin's data file(s) is usually regarded as an implementation detail of a plugin, so the data files location/structure can be changed in any update. Therefore, other plugins which rely on finding data files in previously used locations or structures may break as a result of routine maintenance to PluginA. API methods resolve this problem because they are usually an explicit contract, where any backwards incompatible changes will be documented in release notes, and the version number of PluginA increments appropriately according to semantic versioning (if the developer is following that versioning pattern).
WhiteThunder
A common recommendation for scenarios like this is to add an API method to PluginA, and to make PluginB call that API. An API method is basically just a method that is documented and maintained by the maintainers of PluginA. PluginB can call the method of PluginA by first obtaining a reference to PluginA (usually by defining a field with [PluginReference] attribute which gets auto assigned the plugin instance), then call it like
PluginA.Call("MyApiMethod", arg1, arg2). The documentation on this site goes into more detail.
If you are wondering why API methods is recommended over having PluginB read PluginA's data files directly, it is a matter of best practices. The location and structure of a plugin's data file(s) is usually regarded as an implementation detail of a plugin, so the data files location/structure can be changed in any update. Therefore, other plugins which rely on finding data files in previously used locations or structures may break as a result of routine maintenance to PluginA. API methods resolve this problem because they are usually an explicit contract, where any backwards incompatible changes will be documented in release notes, and the version number of PluginA increments appropriately according to semantic versioning (if the developer is following that versioning pattern).
So that plugin B can make some calls through the return value of the API? He can't modify the data in plug-in A, right?
The API can return anything. The API doesn't have to be readonly; it can be designed to allow other plugins to make changes as well. That's up to how PluginA works. This approach can be used for anything.
The API can return anything. The API doesn't have to be readonly; it can be designed to allow other plugins to make changes as well. That's up to how PluginA works. This approach can be used for anything.
Ok, I will see how other plugins are written, thank you for your answer