We’re working in a public .Net project to integrate with Unity. While right now it’s not the case, eventually we’ll end up referencing Unity components, such as Vector3. The VisualStudio solution will end up containing a reference to UnityEngine.dll. The project will be publicly available. I’d prefer it to be buildable from checkout, instead of having to tell people “Oh, and copy your UnityEngine.dll here”, but I wonder if it’s kosher to have UnityEngine.dll publicly available on a repository, outside the rest of the Unity distribution.
Have you PM’ed Tom on this? While I think its a very nice piece of information to have available on the forums, I know Tom is quite busy at the moment and I’d hate for him to miss this post - as I imagine he would.
To be fair though, Emil’s suggestion is a good one, if you have pressing needs for information, especially about whether something you want to do is legal, ok, kosher, whatever, then it’s best to ping me directly (PMs or even emails, I’m here to help).
On to the real meat of things… I’m not sure whether that’s ok to do or not, but my immediate response was in fact to say that it’s not. But before doing that I’d like to consult with others here internally and get back to you when I have a solid answer to offer. Stand by for that!
Hu?
you have been able to get UnityEngine work with any .NET project?
If so any chance for sharing how, because for me it blows up the moment I try to use any call within it (even if only the networking) independent if .NET 2.0 or 3.0
Not sure what to tell you, Dreamora, so far we’re not using a lot of the functionality (mostly Mathf and Vector3) and things are working. Could it be that whatever you’re using depends on some other DLLs? I’d suggest using Reflector to peek in.
I’m doing this as well from time to time.
You should realize though that a very very large part of the implementation of UnityEngine.dll is handled by calling out into the untiy c++ engine that embeds mono.
The stuff in UnityEngine.dll that is implemented in plain CIL works. stuff that does internal calls won’t work and will throw exceptions. You can use some CIL analysis tool to figure out what calls do and what calls do not do this. I think even MoMA might be able to tell you.
The main interest were the networking ones to do a windows based server, but that stuff seems to be Unity dependant (not mono as even mono will blow up when trying to use them)
recently we licensed unity to create a multiplayer project wich is bigger than to be hosted by unity’s own networking system.
we took a look at many backends.
as dreamora knows our choice was exitgames’s photon but we did not like to implement anything from scratch there. they told us they are working on something to integrate physx or other libraries to make writing logic on server easier.
i think you should make things simpler by making it possible to use unityengine.dll or even the main C++ based engine in other places like normal C++ or .NET projects.
unity is a great platform for creating multiplayer browser based games but this limitation is against your policies of ease of use.
torque like engines have a big advantage in these situations because even the source is available. the source is not needed but please provide a solution sooner to make it easy for all teams in all sizes to make MMOs.
i am sure that you want that as much as we want it.
there is another solution to create a powerful MMO server for unity in partnership with backends like photon or on your own. then you can compete with MMO middlewares like hero engine too. your client engine is the main goal for you but integration is making problems here.
i know that features with less votes will be implemented if possible.
my request for having components in external assemblies with 15 votes is being implemented. however the reason might be that other users that love this feature are big community members like jashan or the staff (angry ant)
