You find tons of cool plugins in the asset store, especially ones that enable some native functionality on iOS/Android, etc. and after installing a few of them conflicts, xcode errors and general headaches start.
Each android plugin comes with some changes to the manifest file, each ios plugin has it’s own postprocessor, etc.
As these plugins are becoming so commonplace and necessary for many projects, it would be great it Unity or some brilliant dev created some sort of standard system that helps to make plugins work well with each other. Like a build pipeline system of some sort for each platform, that way asset developers could just include some standard XML file or something that has a list of what DLLs, frameworks, etc… their plugin uses.
Anyways, just a thought. Would love to get some feedback from other people on how they handle this situation or their ideas for how to solve this problem.
Plugins are a pain sometimes. They don’t work on iOS7 or they conflict with themselves or they don’t work with Unity 3.5.7 or work 4.x. Or they only support iOS or only Android, or don’t work in Web… Each plugin has it’s own restrictions and it gets old.
As much as I like Prime31’s plugins, of late, I am pulling away from them. I have to pay for each extra platform, for the same functionality, and they are starting to conflict with each other. For instance, I recently had to delete the Etcetera plugin, cause it conflicted with some new upgrade they did to their core engine for the Flurry/App Store. Sigh…
It’s rare but some have it. Can’t blame people for not including it as a week later someone else will have a “lighter” version for 1/4 the price on the asset store.
The kinect face tracking has the source, looking through it, it was great to see a visual studios kinect project example brought into unity.
Ahh. I can understand people wanting to protect what can be weeks or months of hard work, but the Unity Asset Store really is a different kind of market. I’m sure many of the source-included plugins get pirated but that holds true with any piece of software. Personally, I think it would be nice if including source code was a requirement for the Asset Store. Too many times it seems that not only do you have conflicts like the above stated, but the developers disappear or they don’t update their plugins to work with newer versions of Unity and the end users are just out of luck.
It’s hit or miss… depending on who reviews it. For my last published version they removed the link to the product site and told me it violated the T&C’s. I also sell my asset via FastSpring. I asked which term it violated and was told it was the term that prohibits publishing assets whose primary purpose was to facilitate sales outside of the asset store… and apparently since the product page has links to both FastSpring and the Asset Store it violates that term.
I asked for clarification as to how I violated the T&C’s since the purpose is absolutely not to sell elsewhere and that the vast majority of my sales are through the Asset Store. I received no further reply. I have a feeling it’s the verbiage on the page that tells folks there’s an advantage to buying through FastSpring (instant access to updated versions) but no one was willing to clarify for me so I just won’t link to it in the product description.
So, a little wander off topic there… but the point is, it completely depends on who is reviewing the product. They obviously don’t have the time or resources to verify that every plugin works as advertised but it would be nice if they did.
I think this is an important discussion to bring Asset store developers into. The ones I’ve talked to agree that there needs to be some standardization and the best thing would be in Unity was able to provide that framework for asset store developers to integrate with. Right now it’s just the wild west.
In terms of source code, sure it’s a valid concern, but that really is a business decision for the asset store devs. I think that it should be optional, not forced. It’s the kind of thing that can be an added value to a higher priced plugin or a pro version of a plugin for those of us who need that full control. The majority of devs are buying these plugins to make their lives easier and to save time, and I don’t think it’s a stretch to say that the simpler and easier to integrate a plugin is, the move value it adds to what the asset store was intended to be.
If you’re an asset store developer, or you know one, then ask them to join in on the conversation. It would be great to see some concrete suggestions for what could be done in the community or by Unity.
I agree that source is preferred, but full source as a requirement might limit some products. Not from a “protecting your work” point, but from a practical one. Though rare, there are some plugins (like the QT one or Logitech one), that utilize a dll that isn’t just complied Unity code, but are external applications themselves that are accessed by Unity. In cases like this, the source would probably be useless to the end user (not having the tools/libraries to compile it from source) and licensing agreements related to the source may not allow for distribution.
Granted, they are rare, but I wouldn’t want limits to prevent these tools from being available. But I agree that compiled code as “source protection” doesn’t really fit the use of the asset store or needs of its users.
That’s a really good point. I think the majority of the issues really boil down to quality control. The time it takes to get an asset published (or even updated) is pretty sporadic. For my asset they’ve ranged from one full week down to just one day. Unity could test to ensure assets at least meet the promised functionality but if they did we’d see much larger delays in getting those assets published. I wouldn’t mind seeing that as long as updates were fast tracked because many times they are bugs discovered by users that need fixed pretty quickly.
That being said… Unity is not our personal QA team and they shouldn’t be expected to be bug hunting. However, they probably should look at maximum supported versions as well as minimum supported versions. Just because an Asset works in Unity 3.5 and above now doesn’t mean it will work in all future versions and it probably should be accounted for. As an example, my JSON .NET asset has some shims in place to fix or replace missing mono functionality to ensure compatibility with iOS and the .NET Subset. If Unity 5 rolls around and upgrades the version of Mono being used, I will need to make some fairly significant updates to ensure that it maintains compatibility, though that is likely a long ways out.
