At some point we need to make a decision on the enums common with Outpost2DLL. Do we include Outpost2DLL as a dependency, and pull the enums form there, or do we duplicate them in this project?
If we duplicate, we are free to rename, which allows us to fix the misspelling in one of the enum names, and update the names for style consistency. We also avoid adding a project dependency. Currently OP2Internal is standalone.
If we import the enums, it may make for a more seamless experience if someone is using both Outpost2DLL and OP2Internal together. This may not actually be as big of an issue as it appears though, for two main reasons.
The first reason being, even if having a new name creates a new enum type, both names would auto convert to integers, which is how old style enums are processed. We can not convert the Outpost2DLL enums to enum class, since the fixed name mangling prevents the changed enums from linking up with the old mangled names. We could potentially convert new enums to enum class though, and add auto conversion methods between the new type and the old type.
The second reason, and this one is currently more theoretical, is that it may not be necessary to mix Outpost2DLL with OP2Internal. Outpost2DLL is restricted to the officially exported interface provided by Outpost2.exe. OP2Internal is free to provide any method from Outpost2.exe, be it a private internal one, or one of the standard exported methods, and is free to rename any of it to anything it wants. Though we should of course avoid random confusing unexpected renames whenever possible. Freedom is no excuse to be sloppy. Personally, I would prefer maintaining seamless compatibility whenever possible. Long term though, as the functionality in OP2Internal fills out, it may be possible to build levels and mods against OP2Internal without relying on Outpost2DLL.
At some point we need to make a decision on the enums common with Outpost2DLL. Do we include Outpost2DLL as a dependency, and pull the enums form there, or do we duplicate them in this project?
If we duplicate, we are free to rename, which allows us to fix the misspelling in one of the enum names, and update the names for style consistency. We also avoid adding a project dependency. Currently OP2Internal is standalone.
If we import the enums, it may make for a more seamless experience if someone is using both Outpost2DLL and OP2Internal together. This may not actually be as big of an issue as it appears though, for two main reasons.
The first reason being, even if having a new name creates a new enum type, both names would auto convert to integers, which is how old style enums are processed. We can not convert the Outpost2DLL enums to
enum class, since the fixed name mangling prevents the changed enums from linking up with the old mangled names. We could potentially convert new enums toenum classthough, and add auto conversion methods between the new type and the old type.The second reason, and this one is currently more theoretical, is that it may not be necessary to mix Outpost2DLL with OP2Internal. Outpost2DLL is restricted to the officially exported interface provided by Outpost2.exe. OP2Internal is free to provide any method from Outpost2.exe, be it a private internal one, or one of the standard exported methods, and is free to rename any of it to anything it wants. Though we should of course avoid random confusing unexpected renames whenever possible. Freedom is no excuse to be sloppy. Personally, I would prefer maintaining seamless compatibility whenever possible. Long term though, as the functionality in OP2Internal fills out, it may be possible to build levels and mods against OP2Internal without relying on Outpost2DLL.