Hello everyone.

We have decided to phase out the Mixed Reality Forums over the next few months in favor of other ways to connect with us.

The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.

The plan between now and the beginning of May is to clean up old, unanswered questions that are no longer relevant. The forums will remain open and usable.

On May 1st we will be locking the forums to new posts and replies. They will remain available for another three months for the purposes of searching them, and then they will be closed altogether on August 1st.

So, where does that leave our awesome community to ask questions? Well, there are a few places we want to engage with you. For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality. If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers. And always feel free to hit us up on Twitter @MxdRealityDev.

Difficulties using Unet on different platforms because I have to use 2 projects.

AdurnatAdurnat
edited June 2017 in Questions And Answers

Hello everyone,

I am trying to use a computer (server) in order to communicate with my HoloLens (client), using Unet. I've had some succes so far (SyncVar works great) but I've encountered a brick wall : I can't send commands from the HoloLens to the PC for many reasons and the main problem is that I am using two differents projects : one for HoloLens and one for PC. More preciely, the Player Prefab won't spawn on the client, and I'll have the error "Failed to spawn server object".

The thing is, it seems to be impossible to have only one project because I can't build for PC when the HoloToolkit is added. I created a new, empty project, added the HoloToolkit package, tried to build on PC and ended up with the following error messages :
"Feature 'asynchronous functions' cannot be used because it is not part of the C# 4.0 language specification"
"Feature 'null propagating operator' cannot be used because it is not part of the C# 4.0 language specification"

I have no idea how move forward, any help would be appreciated.

Edit : even if I try to bypass those two errors, I immediatly got dozens of errors looking alike :
"The type or namespace "Something" could not be found. Are you missing an assembly reference?"
And in "Something", you can replace it with any word you want in the dictionnary : Windows, Tasks, Sharing, Input, etc. I have 60 errors so far.
On the Unity forum, people have highly recommended me to use only one project instead of two so I'm completely stuck here.

Best Answers

  • ReeleyReeley ✭✭✭
    Accepted Answer

    Yes i do use the Holotoolkit, i only have HoloToolkit and HoloToolkit-Tests imported in my project. And i only have to apply the WINDOWS_UWP in my own scripts when im doing some asynchronous stuff like accessing some files. I dont think you have to use WINDOWS_UWP for the HoloToolkit itself, this sould work without it.

    maybe you wraped something wrong with WINDOWS_UWP and that why the error is coming, i dont know :/

    Currently its a pain to code something for Hololens because of C#4.0 but to give you a heads up C#6.0 is coming with the 2017.1 version :D

Answers

  • @Reeley Thank you for your answer. It sounds like a promising solution, but I have a question : are you using the Holotoolkit in your project too? Because I tried to apply this to every script showing an error when debugging (and obviously they all came from the HoloToolkit).

    I just copy-pasted #if WINDOWS_UWP || UNITY_EDITOR and #endif at the beginning and ending of almost every script giving me an error, which meant almost 30 scripts, but it seemed a rather gambling thing to do. Although I'm now down with only 1 error that I don't know how to fix (type or namespace not found even though it should be accessible by the script), I suppose there is a better way to achieve your suggestion?

  • ReeleyReeley ✭✭✭
    Accepted Answer

    Yes i do use the Holotoolkit, i only have HoloToolkit and HoloToolkit-Tests imported in my project. And i only have to apply the WINDOWS_UWP in my own scripts when im doing some asynchronous stuff like accessing some files. I dont think you have to use WINDOWS_UWP for the HoloToolkit itself, this sould work without it.

    maybe you wraped something wrong with WINDOWS_UWP and that why the error is coming, i dont know :/

    Currently its a pain to code something for Hololens because of C#4.0 but to give you a heads up C#6.0 is coming with the 2017.1 version :D

  • Thanks for your help ! Great news concerning C#6.0, it will make things extremely easier for everyone.

    I don't know why but it wouldn't build with the holotoolkit. I downloaded the official Github version called HoloToolkit-Unity-master so I don't know what could have gone wrong. However, I applied your suggestion on every script that showed an error and I was finally able to build for PC without error and even communicate with unet in localhost ! So thank you very much.
    I haven't deployed on HoloLens yet because my Visual Studio licence is currently expired but I'll try this ASAP and will notify if it works.

    For people in my case, here's what I did :
    If a script with an error didn't have any target platform, I just wrote #if UNITY_EDITOR || WINDOWS_UWP at the very beginning of the script and #endif at the very end.
    If it had one like UNITY_EDITOR || UNITY_STANDALONE, then I just erased the UNITY_STANDALONE part. It may seem brutal but it worked.

    Note : Yes, it is a very tedious task. I had to do this on maybe 20 or 30 different scripts.

  • stepan_stulovstepan_stulov ✭✭✭
    edited June 2017

    @Adurnat

    I will try to put a definitive end to platform dependent compilation misunderstandings.

    UNITY_EDITOR is not a platform parallel to UNITY_STANDALONE or UNITY_WSA or others. It's not a platform at all. It's a perpendicular dimension/axis, speaking in vector algebra terminology. Each piece of code can be run as #if UNITY_EDITOR (if, well, run in the Editor and if actually possible) or as #if !UNITY_EDITOR (if run as an actual built application) regardless of the platform in the Build Settings. So constructs like UNITY_EDITOR || UNITY_STANDALONE are a conceptual nonsense, if I may, as they kinda of put the two in the same category, which they aren't. It's like saying "if it's soft or cold". I'd recommend avoiding these constructions. You will find a lot of this stuff all across the Internet though. Sadly even in the all-hailed HoloToolkit. So stay alert.

    I have a similar case to yours, where I have one Unity project that actually builds to multiple networked applications.

    Here is how I do it, and so far very successfully.

    First I defined my own custom scripting symbols one per target application. For example, say we have a client and a server, you'd have:

    BUILD_CLIENT
    BUILD_SERVER
    

    Then, I'd surround each file with in the header that combines the target application(s) as well as supported platform(s). Both groups may occasionally be empty or contain more than one entry.

    // For client
    #if (BUILD_CLIENT) && (UNITY_STANDALONE || UNITY_WSA)
    
    // Both client and server, any platform, mostly shared network protocol
    #if (BUILD_CLIENT || BUILD_SERVER) && ()
    
    // For server
    #if (BUILD_SERVER) && (UNITY_STANDALONE)
    

    And then, should some parts of your script be only runnable in the Editor, surround them with #if UNITY_EDITOR so they're excluded from the build.

    There is no one strategy of using compiler symbols and you will meet great inconsistencies all over the Internet. In any case I advise to always know what you're doing and not add/remove the symbols until it suddenly magically compiles.

    Here is a good overview. All the vector algebra stuff I said is only implied, while there is no definitive explanation on that from Unity side. I must admit the whole collection of predefined symbols is interwoven enough, let alone your own stuff:

    https://docs.unity3d.com/Manual/PlatformDependentCompilation.html


    PS: @Reeley cheers for the C# 6.0 update.

    PS2: UNITY_WSA and WINDOWS_WSA are not the same although may often coincide. UNITY_WSA is a platform define, while WINDOWS_WSA is, if I'm not wrong, for native code injections under that platform (a nested define), which is why C# 6.0 features work. These peaces of code are left uncompiled for the Visual Studio to compile them. This confusion is very natural since native UWP code is also C#, although its newer version. It's quiet a circus at the moment when developing for UWP really...

    Building the future of holographic navigation. We're hiring.

Sign In or Register to comment.