Conversation
|
The reason that I only allow loading one addon from a single assembly is that I don't see why you would want to have multiple addons in a single assembly. You can use addon packet IDs to send different kinds of data from client addon to server addon and vice versa. What is the reason that you are wanting to have multiple addons in a single assembly. Of course, if you can justify this, I'd be happy to lift the restriction. |
Extremelyd1
left a comment
There was a problem hiding this comment.
Apart from my comment asking for reasoning for the PR, the changes seem to contain another PR as well, namely #112.
There are structural reasons one might want different addons in the same assembly; in my case, I'm modifying TheHuntIsOn to add server-pause functionality as its own module. For this functionality to be in the same addon as the EventNetwork module would require tightly-coupling unrelated code, and adding a bunch of conditional handling for pause-related messages on an instance that doesn't support pausing. It was much cleaner to structure the code as two addons rather than one addon with a bunch of conditionals. I was also surprised to learn that multiple addons works fine with a local server but not a dedicated one. |
|
I've added the |
|
Any ETA on when this will be released? Would like to close out Korzer420/TheHuntIsOn#10 too which depends on these changes |
|
It has been released now @dplochcoder, sorry for the delay. |
|
Thank you! |
Making a separate PR for this. This changes the addon loader to allow multiple addons from singular linked assemblies.
There was a comment saying this was intentionally prevented, but I was not able to discern the reason neither locally nor from commit history. Multiple addons from the same assembly appears to work fine for ingame servers, so I'd like to lift this requirement for dedicated servers as well if possible.