So, time ago I made this command system mutator including an unfinished module to communicate with other devices/softwares. Few days ago Dizzy told me that being able to use different programming languages to create mods for UT would be very cool, so I told him about the command system, I didn't release new versions since I don't think someone ever used it, but today I took the TCP class I had there and put it into a separated package, to create a mutator that the only thing that does is communicating with other softwares through TCP, for now it just takes console commands from TCP(better if the client which sends the commands is the localhost, so that there won't be a high ping) and execute them:

Doing it through TCP reminds me of an idea I had once about doing a mod consisting in using multiple UT servers as a single persistent cluster, and which I would use both UDP and TCP, with a central controller in some other language.

I didn't really dig much yet on the link classes from UT, but if you meant to use sockets, in Linux at least it would be best to use a local Unix socket instead for that communication, as it doesn't suffer from the needless complexity and lag (comparatively speaking) which TCP introduces.But I don't really know if UT supports Unix sockets at UScript level.

Adding to this, real support for a secondary programming language in UT is possible I believe, such as Lua.But the entire API would need to be written natively in C++ to create an interface between Unreal Engine and Lua itself in the same way you have UScript with the engine.

Would it be worth the trouble? Maybe, maybe not. In terms of speed, if LuaJIT is used for instance, we're talking about one of the fastest programming languages all around in existence, it gets extremely close to native performance, making it far faster than UScript, plus you get to be able to go beyond that and be able implement and fix things you wouldn't be able otherwise.However, replicating the entirety of the classes to Lua, and since Lua is weak-typed and follows a completely different paradigm, it might prove to be too much of an hassle to be feasible.

For instance, Just Cause 3 has a multiplayer mod made exclusively by the community, and this mod can be developed for in NodeJS (server-side) and by using CEF (client-side), thus being both Javascript, for both the frontend and backend.And thus far their API has almost nothing, not even the bare essential things to even create a mutator or a gametype, but you can pretty much design a beautiful UI through HTML and CSS due to the usage of CEF (Chromium Embed Framework).But they didn't have access to public headers like we did, they had to reverse engineer a lot of it, and maybe had a few hints from the actual developers of the game as they ended up endorsing the mod, so I believe we can do more powerful things.

However, at the end of the day all of this would require native modules to interface with each respective language, and unless there was an effective and trusted way of distributing these, all of this development would be pretty much for naught. Might be an interesting project to take on as a hobby, but as something more to develop more serious mods for UT, I just don't see that happening, unfortunately.

Personally I am planning something however, but on the very long run (something to start maybe several months or a year from now, if at all), and it's not the usage of an existing outside language, but rather kinda creating my own in a way with the current UScript itself. Something more limited than UScript, but more accessible and easier to do things on by players, without necessarily any performance hits or minimal ones through actual compilation and tokenization through normal objects.But there's still a lot I need to do first in and outside of UT first for this to be even worth the trouble, so it's not something I am going to start anytime soon.

But if someone else comes along and does something similar, or brings another language in the meanwhile, I am certainly going to look forward to it.

[quote="nogardilaref"][/quote]Well the workflow I was thinking about is like this:- A TCP class to interact with other softwares.- A module parent class which contains all the possible primitive types and their textToType/typeToText converters.- Child modules, for example the module "StandardFunctions" contains all the possible standard functions name and their parameter names with the respective type names.Anyone could create a module for whatever class/classes that uses functions.In case the external software would require Unreal to execute a function, the TCP message to send should have keys like these: "class1"; "c1function1"; "c1f1param1"; "c1f1type1"which would mean: "Execute the function1 declared inside class1 using the param1 which is of type1."This would be pretty useful to call native functions, since they couldn't be recreated outside, unlike non-native functions.

Sweet memories from years ago when I wrote a bot that would autonomously move a player through a level.

Since bot-pathing wasn't working as client for some reason, a small UDP actor would communicate the UT99 client with a Unreal227 server running a 'similar' map with even better bot paths, automatic map switch was also possible.So the player would do all navigation stuff in the U227 server and then receive the paths through the socket.Managed to put it to play on the uk|Siege server for a couple of matches, and the bot wasn't even last on his team despite it's horrible slow turning speed aim and flak cannon preference (couldn't use ZP weapons due to ACE lol).

Latency sucks though, but it's pretty much the only way to interact with the game outside of native code or cheat-type hooks.

Perhaps a way without directly recurring to native nor TCP, would be to create a compiler which is able to turn code in another existing programming language into UScript.TCP sounds awful for something local, although it sounds great for something controlled remotely.

Something like this is not unheard of, in fact this is actually what things like TypeScript are. TypeScript is nothing more than a structured typed language which in the end compiles into Javascript files, and it was created so developers could become a lot more productive and enforce certain patterns into their code to actually be readable and maintainable (because raw Javascript is one of the worst languages there is).

One of the things I was actually thinking in doing as well eventually, was to actually extend UScript in such a way that you would be able to use things like ternary operators for example, which during compilation would be turned back into "if" statements to be recognized by UCC itself.Although maybe someone already did something similar, idk.