The normal way would be to indeed combine the learn and send action into one.
However, I see your use case now and it does make sense to store this data in a place both actions can access.
You always have access to the EG.plugin namespace, everywhere inside your plugin.
- in actions you would call self.plugin.something
- in your main plugin code (like in __start__()) you would call self.something.
This will access the same data.
However, this data is not saved persistently and is only available during the runtime.
Basically what you need is a "database" for your learned codes, EG doesn't have something like this on default.
Sure, there is EG.PersistantData, but it's not advisable to use it from inside plugins for these reasons:
- can be easily altered and overwritten by other plugins or user configurations
- will never be cleaned up: meaning, even when your plugin is removed or uninstalled. The data you stored there remains in the user's config. This leads to orphaned data that can cause all kinds of issues and also making it hard to reproduce troubleshoot issues with your plugin for you later.
What is done in other plugins is DIY when it comes to storing data, usually file based.
For example you could create your own plugin specific .xml or .json files to store your data in.
You would just dump your variable in self.plugin to that file whenever you learned a code and parse the file into the variable at startup