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

[DsyD]

Does anyone know if it's possible to upgrade UE4's embedded Chromium version? It can't be as simple as downloading the latest Chromium source and rebuilding the plugin with it, can it?

[DsyD]

For anyone who's using VSCode, I put together a simple type declarations file for this so I could get autocompletion/Intellisense working:

declare const ue: {
    /**
     * Object providing communication with UE4.
     *
     * The `broadcast` method sends data to UE4.
     *
     * All other properties should be functions to be called from UE4 by the `Call` function of the WebInterface widget blueprint.
     */
    interface: {
        /**
         * Sends data to UE4 by calling the 'OnInterfaceEvent' event dispatcher.
         *
         * @param name Pseudo-event name to be passed to the `Name` event parameter.
         * @param data Optional value to be passed to the `Data` event parameter as a UE4 `JSON Value`.
         */
        broadcast(name: string, data?: any): void;
    } & {
        [key: string]: (data?: any) => void;
    };
};
/**
 * Alias for `ue.interface.broadcast`.
 *
 */
declare const ue4: typeof ue.interface.broadcast;

You can save the above into a d.ts file (I named it "ue4.d.ts") and then add this line to the top of any Javascript file to get Intellisense in VSCode:

/// <reference path="[PATH_TO_FILE]" />

where [PATH_TO_FILE] is the location of the ue4.d.ts file. It should provide Intellisense for Typescript files, too.

[Edit] Added some docstrings.

[vara.lucsa]

Thanks you for the plugin!
This works great except my editor freezed when enabling web-gl on 4.23.1.
Any suggestions?

[spidershift]

astlouis44 I think that's a great idea. There should definitely be a web-focused game engine and a web-based editor is icing on the cake. There is no question Tim Sweeny is naive because anyone involved in web technologies knows that web-based applications are the future. I always tell people that "one day applications will no longer be installed" and like to use the example of "why install Photoshop when you can go to photoshop.com and start editing" along with comparing it to Google Docs and how most people don't install Microsoft Office these days because you can do Word/Excel processing completely in the cloud.

There is no question games have been going in this direction and will continue to over the years. Yes we are constantly pushing the limits of graphic fidelity and because of this texture sizes and whatnot continue to be insane, always pushing hardware to the limits (and that makes it difficult to apply to web-based games). But at this point it seems like they are getting into more cinematic development because while real-time ray tracing is great, it doesn't really offer all that much improvement to actual games. How about we actually finish the forward renderer first? I mean it hasn't been updated in 3 years now and still says "experimental" on the documentation yet they advertise it directly on the unrealengine.com homepage...talk about FALSE ADVERTISING!

So as you said it definitely seems this engine development is putting focus in completely different areas. I already tell people that "UE4 is NOT a networked multiplayer engine" because let's face it when it comes to dedicated server this engine is a joke. They just added the ability to set your server name and whatnot via command-line arguments in 4.23 which is like 4-5 years after they initially added Steam support. It was 100% hard-coded this engine time! Not to mention the networking/replication for the character movement system is some of the worst networking code I've ever seen in an engine. It's just so pathetic.

But yea I definitely think a push for a web-based game engine would be a step in the right direction because it doesn't seem like these guys here care much about anything that actually matters. It's all about adding more junk to create an impressive engine release each iteration without any focus on what us game developers actually need...

[astlouis44]

spidershift It's a true shame that HTML5 has been deprecated. Our startup has been going all in for our FPS game we're making that targeted WebGL, and it performs really well. With the addition of multi-threading, 64 bit addressing for more memory, the browser can and will be the next big gaming platform. I emailed Tim Sweeney about this, pitching him on the vision that I and other developers have. I figured he would be open to committing further to the development of Unreal's support for WebGL, but this is what he had to say about it:



I think he hasn't checked out HTML5 recently, because there's been massive improvements to all these "low points" that he mentioned. Funny enough, shortly after this email correspondence, HTML5 support was deprecated. Now that I think about it, to expect a company like Epic to commit further to WebGL while they have so many other areas they are focused on (Fortnite, UE4 in enterprise, Epic Games Store) was naive. So I have a proposal for anyone out there who shares a similar vision of gaming on the web that I do:

- A web first game engine with an editor that can be launched on the web, but made for the web from the ground up.

To further complement this, I'm also building out a browser-based gaming platform for indies, to help empower them to find their early adopters using this innovative new way to distribute their work. Am curious what everyone thinks of this idea. And remember, if you want to currently export a game to the web, you'll have to use Unity/Godot if you want to target WebGL. Epic sadly doesn't have the time of day for this anymore...

Except to migrate it over to Github as a "community-supported platform extension"... So this means it will be up to us as a community to band together to push this thing forward, and show Epic how wrong they are about abandoning this awesome platform!

Link to our Discord server for those interested: https://discord.gg/cFJV6Yu

[spidershift]

See guys this is exactly what I'm talking about in my HTML5 comments...

https://forums.unrealengine.com/unre...48#post1660248

Imagine being so lazy or incompetent that it's been 2 months since 4.23.0 was released and there still isn't a 4.23.1 hotfix (which is always released the following week). How much you want to bet most of the engine development resources were pulled away onto the new season of Fortnite instead? If only Source 2 would come out already because this engine is such a joke...

[Tumenor]

Our plan is to compile it into one single file, using a tool like webpack. Makes it easier for us to swap out the files when needed, and maintain the folders as clean as possible. As bandwidth and latency is not a concern locally, there is minimal gain by sharing assets with different other UI's.

We've yet to test this, so feel free to correct me Spidershift

[DsyD]

Yeah, jQueryUI does still seem to work pretty well - I'll give it a try!

How do you manage imports? Is there some way to run a local server on game start, or do people use webpack or something to get around cross-origin blocking with local files? Sorry, I'm kind of new to this.

[Tumenor]

Ok thanks! I have been using Bootstrap but it seems a bit heavy and not well-suited to games. I'll check out jQuery UI...

[Edit] Hmm, now that I look at it, it seems like it hasn't been updated in quite a while. Has that been a problem for you? Are there similar options that are more up-to-date?

jQueryUI does indeed seem like it hasn't been updated for ages, but usually we use it for it's functionality and use our own CSS and HTML
Other options to Bootstrap could be Modernizr although I prefer Bootstrap.

[DsyD]

You are correct that the range sliders are fidgety as I have experienced this issue with the example project as well. It was happening well before the transparency update and the new dynamic mouse transparency didn't seem to change the way it bugs out. The entire browser widget is just very buggy when it comes to drag-n-drop operations so there hasn't been a way to address this issue directly in the engine.

However in terms of a workaround there are a few things you can do. The easiest is to just not use range sliders or other weird input elements at all and just use JavaScript for everything. We actually use the jQuery UI for our form elements including range sliders and it removed a lot of hassle. Otherwise another potential workaround if you absolutely need to support native input elements could be to implement some kind of mouse position tracker in JavaScript which would manually remove focus from the slider if the mouse moves too far away. This could be achieved by manually triggering the mouseup event on the input element. But with that being said the jQuery UI is probably your best option with the fewest headaches.

Ok thanks! I have been using Bootstrap but it seems a bit heavy and not well-suited to games. I'll check out jQuery UI...

[Edit] Hmm, now that I look at it, it seems like it hasn't been updated in quite a while. Has that been a problem for you? Are there similar options that are more up-to-date?

[spidershift]

There are two ways to load content in the browser, the first being via LoadHTML() and the second through LoadURL(). As mentioned the LoadContent() function is just a wrapper for LoadHTML() by automatically reading a file as a string from your .pak file(s) and the LoadFile() function is essentially a wrapper for LoadURL() by resolving the absolute path of the file and using the file:/// URL. So we probably want to keep the abstraction of the file system being within the project itself, either by manually utilizing the /UI folder at the same level as your /Binaries or /Content folders or making use of the internal project settings to either copy or package files in your /Content folder.

However you already mentioned a solution which is probably the appropriate implementation within the context of the plugin, and that is to setup your own custom loadSDCard() function within JavaScript. For instance if you load a dummy page using LoadFile() and the "Additional Non-Asset Directories To Copy" as outlined in the documentation you can then setup your own custom file loading function:

ue.interface.loadSDCard = function(url)
{
    document.location.href = 'file:///' + url;
};

And since this page was already loaded using file:/// via the LoadFile() function in blueprints you can call your custom loadSDCard() function with the desired file path once the "ready" event is triggered:

This is not possible if using LoadHTML() or LoadURL() directly since they utilize the http:// protocol and the browser will prevent you from using file:/// at that point. Note that this "dummy file" workaround is not a good idea for production as the absolute path could be different on various devices. The LoadFile() function is internally using GFilePathBase and this may be required to setup absolute file paths on mobile. So another option could be to use LoadFile() but prepend three ../../../ such that you can start your file path immediately after GFilePathBase. Here is how this would look in the example project:

[Tumenor]

Thank you for reporting this, I will look into it. The mobile workaround for data coming from the browser to the engine via the ue4() function is achieved through the URL itself and it's possible that something you have setup is breaking this functionality. However when performing mobile tests on Android the LoadFile() function seemed to work just fine and these URL changes were responsive. Are you sure you are not talking about the LoadContent() function? That is not the same as LoadFile() and manually reads the contents from your .pak file(s) and then uses LoadHTML() internally.

You're right, we are using LoadContent right now for testing and we used LoadHTML prior to that for reading a file on a sdcard. The ideal solution for us would be to allow for opening HTML files outside of the application, we currently store most of our data on a sdcard so we can quickly switch out what we need for each situation. And the LoadFile function did not allow for that, tomorrow I will implement LoadFile and test with that.

Do you have any plans on implementing a solution for opening files outside the application by path?
If not I suppose a solution for us would be to use DOM manipulation after the initial LoadFile, and correct accordingly.

Thank you for quick the response!

[spidershift]

Sorted out the last issue, that was my mistake

What I currently struggle with is the ue4 function on my android phone, I've applied the JS required to make it work however it only works on websites on the internet / local webservers where there is a proper URL, it does not work for me when loading the HTML directly or loading a local file.

I've tried quite a lot, but it only returns undefined and no communication to UE4 is being picked up, I've applied events to both the interface and the URLchange and none of them trigger.

It's using Android Webview 52

Thank you for reporting this, I will look into it. The mobile workaround for data coming from the browser to the engine via the ue4() function is achieved through the URL itself and it's possible that something you have setup is breaking this functionality. However when performing mobile tests on Android the LoadFile() function seemed to work just fine and these URL changes were responsive. Are you sure you are not talking about the LoadContent() function? That is not the same as LoadFile() and manually reads the contents from your .pak file(s) and then uses LoadHTML() internally.

[spidershift]

I seem to be having trouble getting range sliders to work properly. When mousing down on the slider "handle" and dragging, it may move for a short distance but then shortly stops responding. It seems like it stops processing if the mouse cursor moves off of the handle. This is on 4.22.3 editor on Windows 10, with the player controller input mode set to Input Mode Game and UI, with mouse transparency enabled on the web widget. Maybe it has to do with the new mouse-transparency functionality or my input mode?

You are correct that the range sliders are fidgety as I have experienced this issue with the example project as well. It was happening well before the transparency update and the new dynamic mouse transparency didn't seem to change the way it bugs out. The entire browser widget is just very buggy when it comes to drag-n-drop operations so there hasn't been a way to address this issue directly in the engine.

However in terms of a workaround there are a few things you can do. The easiest is to just not use range sliders or other weird input elements at all and just use JavaScript for everything. We actually use the jQuery UI for our form elements including range sliders and it removed a lot of hassle. Otherwise another potential workaround if you absolutely need to support native input elements could be to implement some kind of mouse position tracker in JavaScript which would manually remove focus from the slider if the mouse moves too far away. This could be achieved by manually triggering the mouseup event on the input element. But with that being said the jQuery UI is probably your best option with the fewest headaches.

[Tumenor]

Sorted out the last issue, that was my mistake

What I currently struggle with is the ue4 function on my android phone, I've applied the JS required to make it work however it only works on websites on the internet / local webservers where there is a proper URL, it does not work for me when loading the HTML directly or loading a local file.

I've tried quite a lot, but it only returns undefined and no communication to UE4 is being picked up, I've applied events to both the interface and the URLchange and none of them trigger.

It's using Android Webview 52