uJavaScript

uJavaScript is a soon to be released script engine for Unity. Documentation Site.

 

Can you create scripts in runtime loaded by UI Text/TMP?

 

Yes. JS code from text strings or controls can be ran at runtime. There's an example of entering code from a TMP text area at runtime in the demo project.

 

Wow. Does this allow you to linkup/reference external js files? For example three.js

 

No, and I don't think uJS can run a JavaScript library that complex. uJS is not a full JavaScript implementation and also lacks some newer JavaScript features and objects. The documentation site has a feature matrix that covers what is implemented.

 

Cool. Thanks for the prompt answer.

 

Are classes allowed?

 

Sorry, but class is not supported.

 

structs seem not be working either. These should be added to limitations. is it available for every platform or only desktop (as it's not documented either).

 

Okay, it expected a comma there but it should not be required. Adding a comma to "Test" makes it to compile:

 

And re-running gives one more error with JSObject.Plus:

 

This should work, I'll add it to unit tests and do some debugging today.

 

That's a good point, thanks. I've only tested it on Windows so far.

 

So, C# reflection objects, "console" in this case, had a prototype and that was causing "this" to resolve incorrectly. I'll push out new builds after I do some more testing. Thanks for finding this bug.

 

The update is pending approval on the asset store and I've updated the demos. Thanks.

 

V1.0.1 Released

• Added error message for 'class' keyword not supported.
• Fixed bug with using 'this' in arguments to reflection object method calls.

 

V1.0.2 Released

• Improved performance by about 8%.
• Added list GameObjects by path function to the character controller console example.
• Added create geometry primitives at runtime function to the character controller console example.

 

V1.0.3 Pending Release

- Console function "inspect" now handles null argument correctly.
- Another 6% performance gain in the interpreter.
- Added behavior tree example that demos implementing scriptable UI tool elements such as JavaScript conditional and action nodes.
- Reflected native types now have ToString properly called on comparisons with strings
- Added EngineHowTo.rtf for basic usage of the JsEngine interpreter class.
- Reflection access to static base class properties such as Instance in Singleton<T> now works correctly.

 

V1.0.4 Pending Release

- Changed console inpect() function to display the results in a table format.
- Added behavior tree overview document.
- Fixed some bugs with created new behavior tree scritable objects. Also,
these errors can cause Unity to put the BT editor in a open, but non-visible
state. The only way I've found so far to close the hidden editor is to change
the Unity editor layout (in the upper right drop down menu).
- Added a sub-tree action node that calls a child BT scritable object. No
debug display for the child tree yet though.

 

The Visual Studio unit tests are available on the project site for download.

 

V1.0.5 Released

- DELETE OLD FILES BEFORE IMPORTING. Some files were moved to a new assembly
(/Assets/PortlandSoftworks/PortlandFramwork) or renamed, so you will need to
delete the old ones.
- Sub-tree's are now displayed in the behavior tree editor at runtime.
- Rewrote the lexical analyzer for reduced memory usage and a small performance
improvement.
- The lex changes and numerous code tweaks have improved the performance by
another 5% or so.
- Support code for enhancing the demos was added and tested.
- The Visual Studio unit tests are available for download at:
https://portlandsoft.works/articles/UnitTestsDownload.html

 

V1.0.6 Released

 

Looks promising. Have you had a chance to look into all the devices this supports (Android, iOS, etc.)?

 

Thanks for taking a look. I haven't looked into mobile device builds yet, but there are some limitations with IL2CPP that would also affect mobile. Since IL2CPP only generates Unity and dot net API's if they are directly referenced by your project's code, the full API is not available through C# reflection and cannot be dynamically accessed through the JS interpreter. Accessing types in JS code are not referenced in C# causes "unknown type" errors in builds that are not present in development.