Published in


UGC UI Improvements

Widgets now have customisable properties, making UI so much easier!

Introducing a brand new feature — Widget Properties!

Widgets can now have their properties defined directly in the HTML.

In short, this means less dependence on Lua scripts for populating & customising your widgets. It also makes widgets downloaded from the store easier to use and customise for Creators who don’t want to go in and modify HTML directly.

We’ve introduced this to continue our goal of making all aspects of creation as accessible as possible, and we can’t wait to see what you all do with your UI designs in future.

Properties are defined in the HTML like this:

Each property must have at least a name and a type

At a minimum, each property needs a name and a type. Properties support lots of different types and can include default values in the format you would expect to use in an HTML document. For example, the default value for a colour property can be defined using rgb(), rgba() or hex format.

Check out this tutorial for more information on adding properties:

Once you’ve defined some properties, they can be referenced in the HTML using a properties object. Here’s an example of the default HTML template being converted to use some of the properties defined above:

Properties are referenced the same way as data model values

Each property is referenced using the name specified in the initial property’s definition.

Note that the properties data model is read-only from JavaScript and can only be modified via a Lua script.

Properties can be modified from Lua using the properties accessor on the widget entity. For example, to change the textColor property from the example above, the Lua script would look something like this:

Types are passed to widget properties using Lua syntax

Why use Widget Properties?

On the surface, widget properties share a lot of similarities with data models so why use widget properties? Let’s have a quick look at some of the benefits:

One theme we’ve seen with Community packages with widgets in them is creating a Lua script alongside each widget, which is mostly just an empty script that comprises properties for setting up the widget’s appearance or for populating data on the widget. With the introduction of widget properties, this can all be done on the widget component, which should make it easier for Creators to set up and use widgets they’ve downloaded from the community.

One of the key benefits of widget properties is the ability to expose customisable elements to the editor. This allows creators who don’t necessarily want to open up the HTML source and start making changes to maintain some control over the widget’s appearance. This could range from simple things like the background colour of a sign to the number of slots to show on a leaderboard.

This one is a pretty big deal!

Up until now, widgets have only ‘existed’ on the client. This makes sense because the client is where the widget is rendered, but it also means if you want to make a change to a widget that affects every client the same way (for example, if you want to change the text on a button) you need to use a Lua script to send a message from the server to every client and then modify the data model or call a function on the widget from there.

This isn’t necessary with widget properties; you can now access the widget directly from a server function in Lua and modify some properties, and the changes will automatically propagate to each client.


Hopefully, you will find this new feature useful; we want to make all aspects of creation as accessible as possible so feel free to head on over to and let us know what you think and ask any questions you may have.



Posts by Unit 2 Games staff, mostly about Crayta

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store