Disrespectful behaviour towards Oxide on the part of ScaleBox

Hello! Please could you give some attention to the following issue, as it is quite complex and technical. Unfortunately, I haven’t come up with a ready-made solution, but I’ll try to provide as much technical information as I can.

In the older version of the plugin we were using, ScaleBox wasn’t included. In fact, the entire Custom Seeds file had been completely cleared. Our use case for the plugin simply doesn’t require them.

However, there was a compilation error in this wipe, and whilst we were at it, we updated to the new version of ScaleBox (and that was the mistake). I didn’t pay much attention to it, but after the wipe, major problems with the Loottable began. Additional items stopped dropping from resources; only standard loot appeared.

Digging deeper, all the problems turned out to be consequences of a more significant issue. The plugin wasn’t compiling on load.

After a week of debugging, the culprit was found… And it wasn’t Loottable, but ScaleBox.

Let’s look at the situation. We have two functions:

void A(int, UiRef, float)

void B(int, UiAnchor, UiPosition, float).

By default, the plugin’s context is used, and we’ve declared our `UiAnchor`s somewhere externally.

It’s good practice for this sort of code to set up separate namespaces to prevent conflicts. Let’s say
 

using SamplePlugin.Cui

using SuperSamplePlugin.Cui

Both UiRef and UiAnchor, UiPosition can be declared in each of these. And by specifying the correct one, there should be no problems. But inside ScaleBox, you have shown a blatant lack of respect for the rest of the plugin community. You’ve declared your classes—the ones you specifically need and use—in `Oxide.Plugins`. You’ve essentially said, ‘The entire Oxide ecosystem, take note: ONLY MY classes exist, and I won’t allow them to be used anywhere else’.

And, at the VERY LEAST (I haven’t checked every class conflict), your `UiColor` is also used in `Loottable`, within its internal `Cui` class. Because you declared your code at such a high scope, any mention of `UiColor` in the `Loottable` code was converted to your `Oxide. Plugins.UiColor, whilst any matching in places where Loottable.UiColor is explicitly mentioned simply broke.

So what can you do about this? Please set aside a separate namespace for your internal classes. They do not create any entities, but simply alter the IL signature of your code. That way, you’ll ensure your code doesn’t interfere with anyone else’s.

It’s not even a problem if you, for example, create a namespace within Oxide.Plugins. For example, Oxide.Plugin.PluginComponent.UltimateIndustrialFarm.XXXXX.

Also, whilst this isn’t strictly related to the logic, if I were you, I’d consider integrating ScaleBox directly into the plugin itself. There are now tools available for convenient split compilation. You write your code in various independent plugins, components and so on. Automated tools then assemble this into a single .cs file containing all the code. This will improve development and project organisation for you, whilst your clients won’t have to download lots of additional plugins.

And if anything, you also have conditional compilation techniques at your disposal. You can write #ifdef OXIDE/CARBON, and the block of code enclosed within it will automatically be compiled only on the required platform. This allows you to build a single large plugin that works on both Oxide (by following the Oxide code branches) and Carbon (by following the Carbon code branches).

Apologies for the rambling style and the rather odd way of explaining things. But I think you’ve grasped the issue: move your classes, apart from the plugin class itself, directly out of Oxide.Plugins.

ScalboxCore can't be merged because it's the core that all my plugins will now use.
I'll check.

fixed, rdownload plugin

Changed Status from Pending to Fixed

Changed Fixed In to 1.6.6