SendMessage doesn't work on 5.6 for WebGL?

Hello hydrix.

In Unity 5.6 we are using a new embedding scheme, which allows to embed a properly namespaced WebGL build on an arbitrary page without conflicting with the main page code. For example, now you should also be able to embed multiple builds on the same page. For this reason global SendMessage does not make sense anymore, and you should explicitly specify the instance of the game you are sending your message to.

Each game instance has it's own SendMessage method (as well as SetFullscreen method). The JavaScript code in the html might look like:

Code (JavaScript):

1. var gameInstance = UnityLoader.instantiate("gameContainer", "Build/mybuild.json", {onProgress: UnityProgress});
2. setTimeout(function () {gameInstance.SendMessage("MyObject", "MyFunction", "testData");}, 3000);

Note that you only need to use this external game instance API when you send a message to your game from the global JavaScript namespace. If you are using SendMessage function in a JavaScript plugin included in your project, then the plugin code will be executed inside the corresponding Module namespace, so you can call SendMessage function from your JavaScript plugin directly without using external API.

P.S. There has been a small issue in early 5.6 betas, where API was declared as .sendMessage instead of .SendMessage. This should be fixed now and both .SendMessage and .SetFullscreen game instance methods should start with a capital letter.

P.S. If you want to avoid the reference exception which is thrown in your case while the game is still loading, you can override the onRuntimeInitialized Module method directly from the html using additional embedding parameter, it will notify the embedding page about the module being ready to receive messages.

The documentation will be updated in the near future. Let me know if this helps.

 

Hello Handsome-Wisely.

SendMessage mechanism in 5.6 is different from previous versions of Unity, because staring from 5.6 all the build code is isolated from the main page code. Considering that you have "var Module = {}" in your code, it seems that you are using Unity version below 5.6, in which case direct call to SendMessage() should do the job.

 

Hello nsmith1024.

As @Fizzer suggests, if you already have a lot of code using direct calls to SendMessage on your page and you don't want to refactor it, you can simply use the following temporary workaround:

Code (JavaScript):

1. SendMessage = gameInstance.SendMessage;

The idea behind the new embedding scheme is that the page code can be isolated from the build code, so that you can easily embed your build into any page. Previously there was no such possibility, so some developers occasionally mixed the build specific Javascript code with the page code, which now makes is quite difficult to strip that code out of the page.

If you want to make your build easy to embed on any page, you should consider putting all the build specific code into .jslib and .jspre plugins. Note that Javascript plugins are defined inside the build namespace, so you can use the SendMessage function from there directly.

If you use the workaround mentioned above, then your redefined SendMessage function will logically belong to the page code, not to the build code. It may be temporary used for compatibility, while you can gradually transfer more and more Javascript code from the page into plugins, which are internal to the build.

It is also worth mentioning that embedding scheme is not universal. Generally, if you want to namespace the code, then you should also be able to namespace all of its dependencies, which is not always easy to achieve. Consider a case when your build depends on some external Javascript library, which was not designed with namespacing in mind (i.e. is actively using the global namespace). In such case it might be a bit problematic to embed such a build on a page which is already using a different version of the same external library, due to the dependency conflicts in the global namespace. This means that it is actually the used dependency which prevents your build from being easily embedded on an arbitrary page. For this reason, try to minimize such problematic dependencies (note, that it is not uncommon that developers sometimes drag in a huge external library just to use a small function, which could otherwise be simply stripped out from that library).