Download

FREE: Web UI (HTML/CSS/JS Interface)

Glad you’re finding the plugin useful, and thank you for specifying that you’re testing on an empty project. The UE4 CEF can be used with WebGL disabled (default in 4.23) or enabled (default in 4.24) which comes at a significant cost of performance. You’ll get something much more responsive and a lot closer to 60 FPS if you use a browser widget with WebGL disabled.

There is unfortunately no way to change this setting without compiling the engine from source yourself. The documentation explains exactly what to do. Otherwise if you must use the default engine installations via the Epic Launcher then your only other option is to revert back to 4.23 which quite honestly I highly recommend anyway. There were some major overhauls to the engine in 4.24 and 4.25 and many things are still broken, even in 4.26 which most likely won’t get fixed any time soon, if ever. So I would strongly advise using 4.23 or you’re going to start finding a lot of little issues here and there and wish you wouldn’t have gone so far forward.

Now the fact that you’re getting 300+ FPS in the engine is irrelevant, this is an external subprocess that is sending texture updates to your GPU from your CPU. The UnrealCEFSubprocess.exe runs at its own desired frame rate, which maxes out at 60 FPS anyway when using an external rendering process. The only way to have a web-based interface that runs at the same FPS as your game (meaning it is integrated into the engine and runs on every tick) is to use something such as WebKit instead.

We’ve planned to integrate WebKit for many years now but have just not found the time to take on that project just yet. However it is the only way to get these web-based interfaces working on consoles (although there might be a PS4 workaround) so we are still planning to do that sometime in the future.

Love this Plugin :slight_smile:

Somehow IME doesn’t work for me on 4.26 even using native WebBroswer widget, but I made it work before on 4.24 with custom code below, and added options to show Contorls and AddressBar, Can you intergrade these codes into this plugin? that would be perfect :wink:

Cheers
Storm.

Well if you can read C++ then you must have missed this…

https://github.com/tracerinteractive/UnrealEngine/blob/4.26/Engine/Plugins/Runtime/WebUI/Source/WebUI/Private/WebInterface.cpp#L224-L238

But alright, I’ll add a section to the documentation in the next update about how to enable IME support (cause you assumed everyone in the world uses IME and wants it enabled by default).

Thank you sooo much :wink:

I’m not familiar with C++ just grabed code from somewhere, and here is my wishlist:

  1. if you can add options to show Contorls and AddressBar that would be grateful :wink:

  2. I see upload file to web page works but how to download file from page? if I have a button on page to download the file.

  3. Would you add these features for 4.24 such as load from .pak file or if it’s only for 4.26 ?

  4. any consider to add Tab based featrue? like this https://forums.unrealengine.com/unre…ser-plugin-umg

Cheers
Storm.

Hey guys just a quick update on a useful new feature…but I can’t start without mentioning this awful new forum interface. Not only is it extremely unreadable with the overbolded text but the overall layout and spacing of everything is just ridiculous. Would you expect anything less from Epic Games though? This is like the perfect metaphor for how they treat their engine updates…half-arssed and unfinished.

MAILING LIST

Plus I can’t even edit the first post anymore which means making updates to this thread isn’t really going to be possible any time soon. So since the forums are pretty much bricked what we might do is finally build out our website. Right now there was nothing but some placeholder pages and a link to the documentation, but we could get it all updated with actual images and descriptions of the plugins. Most importantly we would include an option to sign up for an email list so you can get updates about our plugins without having to visit these awful forums anymore. I’ll be sure to let you all know when I’ve taken some time to get that setup, but I definitely think that’s what we’re going to do.

COMMENTS + TRAILING COMMAS

Anyway moving on to the update. We’ve been trying to migrate from using UE4-based INI files to our own custom JSON files. This not only provides more flexibility but also allows you to lock down your INI files so end-users cannot edit those settings (such as rendering or scalability settings to cheat and hide foliage). It creates a great separation between engine settings you don’t want them to touch and your own custom game settings.

What I mean is, you usually have Engine.ini and Game.ini and Input.ini and GameUserSettings.ini and so on all in your AppData folder. But you shouldn’t have any of these in there except for GameUserSettings.ini and maybe Input.ini but as usual these engine developers don’t care at all about security. So buried away deep in the C++ code (without any access from project settings) is a way to disable all INI files except the GameUserSettings.ini which forces these INI files to ONLY be in the PAK files of your shipping builds.

Here’s the problem though. If you do this and start using JSON files as a new file type for your custom settings files, they quickly become unusable due to the JSON standard. It does not support trailing commas and even worse it does not support line or block comments:

json2

Since this is all considered invalid JSON, if you accidently include a trailing comma, your JSON will not parse. If you accidently include a comment somewhere, your JSON will not parse.

So there’s a significant difference between wanting to parse valid JSON for HTTP which should remain strict, and user-edited JSON that could easily become “invalid” even though their text editor had no problem with them adding the comments or a trailing comma.

Therefore the following function has been developed for this very purpose:

RESEARCH + RANT

Now when initially trying to tackle this problem I came across a few examples on Stack Overflow. No joke, some dude tried to solve it with RegEx, was all like “yea I made sure to cover all the potential options” and had an entire explanation about how RegEx will do greedy capturing, ect. In fact this was the “accepted solution” and had over 100 upvotes on it. Can you believe so many programmers are this stupid? Literally the only way to properly parse/capture comments is with TOKENIZATION! That example from Stack Overflow? It can literally be broken in 2 seconds by using an escape character in your strings:

{ "this is a key": "this is a string with \"quotes\" in it" }

And it would have absolutely no idea what to do because RegEx is OBVIOUSLY not the right tool for the job at all. So why bring this up? Because we actually took the time to implement the RIGHT SOLUTION which properly TOKENIZES and knows the context of whether a character is escaped, inside a comment, or inside a string. So you don’t have to worry about “accepted solution” Stack Overflow morons putting inferior code into your games that will ultimately just break the moment someone tries to type a string with a quote in it.

Anyway this function (along with probably some basic load/save .json file functions) should be included in the next update. Again I will let you all know about creating a mailing list so you all don’t have to use the forums anymore for updates.

点击此处以获取中文文档

Thank you for all of your hard works, I really love the new “Load” function and just one question see if you can help:

If it’s possible to access local imges outside of .pak file? since I’ve got my html file packaged inside .pak file I want to be able to replace images without re-package my game.

Thank you so much!
Storm.

No, there is no way to access images on disk when loading an HTML file using the pak:// scheme. This would OBVIOUSLY be a huge security risk from a browser perspective, so it’s not going to happen. If you don’t want to package your game every time in order to swap out the images, why not setup a blueprint like this:

These are things you really need to start figuring out on your own or you’re never going to get anywhere. I don’t mean that to discourage you from making games, everyone has to start somewhere, but you need to learn to become RESOURCEFUL. I wouldn’t expect you to know about the URL schemes or image loading and the browser security and all that…but it never occurred to you to load the widget in two different ways based on development vs production…

There’s some new features being added to the JSON library for conversion between native UE4 structures. The best part is that these don’t just work for C++ structures but also for blueprint-based structures created in the editor. Here is a quick example:

blueprint_struct

These nodes are really easy to use. They have wildcards setup just like the SELECT node, so you just connect whatever structure you want to it and it will figure it out AFTER YOU HIT THE COMPILE BUTTON…

struct_to_json

In the next screenshot an object is initially parsed from a raw JSON string and then stored in a variable called “Json Var” of the type JsonObject. Then the “JSON to Structure” node is called using this variable. It returns a structure of type MyStruct which is a native blueprint structure created in the editor. After that a structure is created of type MyStruct and then passed into the “Structure to JSON” node which returns “Object” of type JsonObject:

This update will also include the stripping of comments and trailing comments as mentioned in a previous post. It should be uploaded to GitHub within the next few days.

A new plugin will be coming out as well for JSON-based assets and settings files. This will be separated from the JSON library plugin as optional extended functionality that leverages the new stripping functions for a relaxed JSON structure in assets and settings files.

Alright so there’s more updates to share. First is that the website is FINALLY being overhauled with descriptions, images, download links, and eventually more detailed documentation as previously mentioned. You should be able to subscribe to our mailing list in the next few days:

https://tracerinteractive.com/plugins/webui

Also since UE4 is winding down and 4.27 may very well be the last version, perhaps it is time to actually fork the CEF which has been inaccessible this entire time due to being placed in a “private” folder by the engine developers. This means there would be no more C++ snippets in the documentation because custom cursors would be fixed automatically. Plus we could implement a toggle for WebGL and everyone that isn’t compiling from source wouldn’t have to suffer any longer with the 4.24+ performance issues.

So all plugins will be updated this weekend with new versions. I know I said last time it would only be a few days but we ended up making a lot of progress on the JSON assets plugin instead. I’m going to make another post about that in a few minutes once I collect the screenshots.

As mentioned a new plugin is in the works which allows for JSON assets. Since the JSON library is a required part of the WebUI plugin and all of you already have it, I’m going to share the progress made so far.

However this functionality also strays away from the concept of web-based user interfaces and instead focuses on raw data. Therefore I’ll most likely make a new thread for the JSON assets plugin in order to keep the discussions separated. But until the plugin is actually finished and available for download there’s no point in making a thread just yet…

The entire concept is based around that of materials vs material instances. So just like how you create a material, and it has parameters, and then a material instance overrides the default values of those parameters; we’ve implemented a powerful data organization scheme that follows this same concept. You start by creating a new asset under blueprints of type STRUCTURE INSTANCE.

1

It will then ask you what structure you would like to create an instance of (similar to how the Data Table asset does). These can be both blueprint-created structures and C++ structures.

2

You can now open this asset and it will look just like the “default values” section of the structure editor.

3

It also dynamically updates when you make changes to the parent structure…

Then you can create a variable of type “structure instance” in your blueprints. It can reference the JSON asset directly and then operate on it as either raw JSON or an organized structure.

5

Plus a great optimization is that this data only calls the parse/stringify functions once during loading and saving of the asset. That means you can reuse a piece of data over and over in different blueprints without needing to constantly instantiate the data.

It also means you don’t have to use blueprints to actually store default values or game settings and can instead move these out into separate “structure instance” assets.

Finally the best part is that these assets can be saved as either .UASSET format or as raw .UTXT format instead…

4

There’s some other annoying UE4 data that surrounds the custom JSON but it doesn’t take up that much space and most of it is located below your data anyway.

7

But this is a significant piece of functionality for anyone that uses source control. Right now with everything being binary .UASSET files it can become quickly annoying when needing to constantly upload entirely new files to source control, even if you only changed one small piece of information such as a default value.

Now instead you can feasibly utilize .UTXT files in the course of your everday development and simplify your assets in source control by properly separating text vs binary data. It’s as easy as right clicking and changing the asset type…

text_asset

So again this is just a preview of the JSON assets plugin and what is to come. I will be making a new thread for the JSON assets plugin once it is available for download.

The WebUI, JSON, and HTTP plugins have all been updated as of 4/26/2021 for engine versions 4.23-4.26 on GitHub. That’s because we actually like, you know, go back to previous versions and update things…unlike the incompetent/lazy engine developers that would never even consider implementing important bug fixes into past versions. Imagine if they actually cared and released 4.23.2 after 4.24 came out? But alas, they have no intention of giving you a “stable” engine build of any kind, hell they can’t even fix extremely game breaking bugs after 4-5 years. Click here for game breaking forward rendering bug that was introduced in 4.15 and has yet to be fixed, so we just hack it out of our source code by completely disabling Alpha2Coverage altogether; they literally couldn’t care any less about VR or MSAA.

Here are the update notes:

  • webui now has forked engine browser to eliminate performance issues
    • fixed performance for 4.24+ without code changes
    • fixed custom mouse cursors without code changes
  • convert structs to json and json to structs
  • parse relaxed json with comments and trailing commas
  • subscribe to mailing list for updates
  • json assets plugin coming soon (check previous post for details)

Here are the download links:

WebUI: 4.26 - 4.25 - 4.24 - 4.23
JsonLibrary: 4.26 - 4.25 - 4.24 - 4.23
HttpLibrary: 4.26 - 4.25 - 4.24 - 4.23

perhaps it is time to actually fork the CEF which has been inaccessible this entire time

Would this mean the browser could be updated to the latest Chromium version?

Yes technically, let me explain…

So basically this update forked the source code that is in your game. That means when you compile a shipping build of say YourGame.exe it has code in there that knows how to launch the CEF. That code does all kinds of things, such as setting the desired FPS, working with the mouse, or applying command line parameters to the CEF (such as enabling/disabling WebGL).

Because this code was all stashed away in a “private” folder of the engine code, it was completely inaccessible and could not be overridden by any plugin code. This code has now been forked, and we can change it as we please.

However this probably changed nothing in terms of updating the CEF itself. Once your game executable is running (for instance YourGame.exe) it launches a subprocess called UnrealCefSubprocess.exe for each individual browser instance. This is the CEF itself, and would be the specific CEF version installed into the engine. It is a completely separate project in the engine and isn’t even in the “runtime” folder but rather the “programs” folder instead.

Does forking the source code from the “runtime” folder help with that? Sure, but that isn’t really the hard part of updating the CEF. As you can see, doing the “runtime” fork wasn’t that big of a deal, it was mostly just a lot of renaming. Doing a “programs” fork though of the UnrealCefSubprocess project would be a lot of work. And compiling the latest version of the CEF itself is a complete NIGHTMARE…

So again doing a “runtime” fork was easy, but we never did it because it wasn’t necessary until they forced WebGL on everyone. Moreover forking such a large piece of source code is BAD PROGRAMMING for the long term. By leveraging the existing browser classes of the engine, the WebUI plugin was always very lightweight and was extremely easy to update across engine versions. Now for instance when reverse updating the fork to 4.24 from 4.25/4.26 where the entire engine migrated from UProperty to FProperty, that fork was now completely incompatible and had to be updated.

If we had done this years ago it would have been a huge PITA to update the plugin for each new release of the engine whenever anything significant was changed, and would have made updates take days or even weeks rather than a matter of hours after new engine releases. This was not something we wanted to do every single engine version. But since the engine is winding down and 4.27 is most likely the last version, it was a lot easier now to compare/contrast the differences and just get it all done at once.

Now with all that being said, we never planned on forking the CEF (even just the “runtime” part iself) especially because the long term plan was to always migrate from the CEF to WebKit. That would completely eliminate the browser subprocess executable and instead would be a WebKit DLL that would be included in your existing game executable. That means the web interface would be ticking/rendering on each game tick, thereby having the same FPS as your game. This is the ultimate end goal, including full console support.

So we don’t really have any plans to update the CEF since it already comes with the engine and supports everything out of the box we’re looking for. You’ve got modern HTML5 and CSS3 along with a decently recent EMCAScript version.

What exactly is it that you’re looking for in a newer CEF version? And are you aware that the CEF is literally bigger than UE4 and takes 3X as long to compile? It’s really not worth the effort unless there’s something extremely necessary…

It’s been a while since I’ve worked on my UI but from I believe there were some things related to web components/shadow DOM that hadn’t been implemented in the UE browser’s CEF version yet. I think constructible stylesheets are also relatively recent? Nothing essential, anyways - I didn’t realize what a pain it would be to upgrade.

Thanks for the response!

No problem, happy to help. Hopefully we can get some kind of WebKit support implemented sooner rather than later. It’s nice to get a question though that is actually about web technologies or constructive discussion about certain features. I’m always available to explain why a specific decision was made or design path implemented; and to discuss ideas, features, workarounds, whatever. Unfortunately most of the time it’s either just people claiming something doesn’t work when they can’t figure it out, and even worse not putting in any effort to actually address their own problem, but rather just expecting some free video game development on top of their free plugin (just like the guy asking for browser tabs and address bars when the entire point of the plugin is to actually develop a user interface yourself and not have any low-level browser features). But I’m always happy to assist someone that is clearly putting in the effort to solve a problem and needs actual assistance.

Hello I am a beginner in the matter, but is it possible to retrieve the html tags from a URL loaded in the browser?
I know it may sound stupid but hey I still prefer to ask …

No need to worry about being a beginner, we’ve all been there. I appreciate you pointing that out though. I assume by HTML tags you mean the HTML source of the page that is currently loaded? This is technically possible but the functionality for it has not been exposed to blueprints. That’s because it’s not really something within the scope of this plugin. It is not meant for surfing web pages or anything that would involve the need to work with HTML source, as the WebBrowserWidget that comes with the engine is more designed for that.

Are you looking to debug your page while you’re working on your game? You can do this with CTRL+SHIFT+I which is also outlined in the documentation. Otherwise perhaps you can provide more insight into what you’re looking to achieve and why you need that functionality?

I also wanted to post a quick note about the JsonAssets plugin. There has been more progress on UTXT assets. First I took the time to compare some different engine versions, and didn’t realize that a few things were updated in 4.24 for text assets.

However while they completely changed the text format itself in 4.24 and fixed a few random bugs (such as text assets not loading in the content browser unless referenced by a binary asset that’s being loaded) mostly everything else remained the same in terms of everything being completely unfinished and unusable. Plus none of this really matted since the JsonAssets plugin already fixed many of these existing engine issues.

The initial plan was to only work with UTXT asset in-editor and then require these files to be converted to UASSET before cooking your game. This could have been taken a step further by automating the process so it temporarily renames UTXT assets while saving UASSET versions for cooking and then resetting everything afterwards. But this is not a good design plan and wasn’t really the long term goal.

Now the thing is UTXT files are not supported by cooked builds, and quite frankly that is probably a really good design decision anyway. So if we’re not going to allow UTXT assets to even be cooked, there was only one clear solution which I’m happy to report we got working…

This is of course still being able to utilize UTXT assets, but then having them cooked as UASSET files directly. That means there’s no changes to your content directory itself, and everything takes place during the cooking process instead.

So now with this new update we’ll be able to work with raw text-based UTXT assets using JSON, then package for ANY platform, and have all this data cooked as binary UASSET files. Unfortunately this did delay the actual release of the JsonAssets plugin as some of this new functionality is being tested really quick. But it seemed like the right decision to just put everything together the right way like this instead of having something half-finished (kinda like the engine devs) with weird workarounds for cooking.