UT SDK for Coding

[The_Cowboy]

Howdy!

I have stumbled upon a page https://www.moddb.com/mods/utcommunitysdk which claims to release a UT99 SDK next month.

Few questions
1. Do UT SDKs include coding components, meaning, headers, especially, 469 ones.
2. Since there are new native toys to play with, yes the celebrated Vulcan renderer, just wondering about the compatibility with VS2022 and QT Creator.
3. If none of the above, how can I contribute to achieve just the same.
4. Just I don't forget, this be continuation of viewtopic.php?t=3993

[Shadow]

Hey there!

Yes I'm really trying to pull of a new version around January, maybe an internal test before. To give you an insight: I'm working on it like 6 days a week, because it has turned out to be that much work. Its an own Engine fork now similar to projects like OpenXR (Stalker) or the Doomsday Engine (Doom/Heretic/Hexen).

1. I'm currently building the SDK with 469a using the 436 official headers, because 469b led to some problems. After a stable release with 469a I'll adapt the SDK to 469c, if possible. The Q1/2023 release wont contain every planned feature and will focus on a stable core engine framework and major level design features like static meshes, materials, anim meshes, a component system. Sprites, Particle Engine, Terrain Generation, UI, Open Shader Framework and so on will follow in Q2/2023 - anything else is unrealistic and I would be suprised by myself, if I would make it before Q2/2023.

2. Because of a PC crash some weeks ago I had to switch from VS 2010 C++ to VS 2022 C++, so it will be compatible with VS 2022 C++ - I do like Vulcan as an API, but have no plans of integrating it (for now). I've focussed on and been using OpenGL for years now. So I'll be happy getting that all up and running on OpenGL, then DirectX second, Vulcan maybe third.

[The_Cowboy]

Nice Job!

About 436 headers, any specific reason(s) for not using 469 ones? I have looked on internet but couldn't find relevant ones. Anth and company haven't released the headers yet, that would indicate.

Native mod developers may want to use our updated UT SDK, which will be hosted in this repository.

They mean different SDK?

However, on the flip side, cheers on making VS2022 work! Again, the bottleneck for Vulcan would be headers because latest update have build dependencies or so I have read!

[Buggie]

About 436 headers, any specific reason(s) for not using 469 ones? I have looked on internet but couldn't find relevant ones. Anth and company haven't released the headers yet, that would indicate.

"Anth and company" released it. Goes to:
https://github.com/OldUnreal/UnrealTour ... ses/latest
And grab zip or tar.bz2 with SDK in name.

[The_Cowboy]

About 436 headers, any specific reason(s) for not using 469 ones? I have looked on internet but couldn't find relevant ones. Anth and company haven't released the headers yet, that would indicate.

"Anth and company" released it. Goes to:
https://github.com/OldUnreal/UnrealTour ... ses/latest
And grab zip or tar.bz2 with SDK in name.

Kudos!! Native modding, here I come.

[Shadow]

Great, so I can finally use 469 headers to ensure 100 % compatibility. Wouldnt have guaranteed that under the "old" 436 headers.

[Gustavo6046]

Just wait until the Rust evangelists come around obnoxiously yelling to "rewrite it in Rust!"... As a fan of that language I'm ashamed these kinds of people exist, bringing a negative light upon it.

I can't wait for the UT SDK to come out! It's a very exciting project to hear about, and seems quite large too. Is there any plan to maybe open-source it in the future? I get that it doesn't make sense in a very early stage to do so, but do not underestimate the power of community teamwork.

Also, @The_Cowboy, "Anth & Co." is a cute way to refer to the OldUnreal dev team. I like it!

[Shadow]

Writing the SDK in a different programming language other than C++ will spawn a ton of problems, since the whole engine is written in C++, not only the SDK. But yeah, I've heard of Rust lately ^^"

Glad to read about your enthusiasm. It has become quite large in the last 2 years and differs in more than 99 % from what was available back in 2013 - mainly because of the component system and a complete new render interface, that uses deferred rendering and draw policies instead of old forward rendering and Unreal Engine's horrible reprocessing mania.

The SDK was open source and will stay open source. It is by far easier to hunt problems and bugs this way together. I simply cant identify every error in my own work myself.

[The_Cowboy]

Great work and philosophy Shadow!!

About the code SDK here is the presents list (for Santa of course) that'd be dope for Christmas
1. Core.so, Core.dylib and static version .a (for Linux and MacOS) and their counterparts for Engine and Window libraries. Multiplatform dev support that is!
2. Symbol files (pdb and all that) for attaching the debugger accordingly!!

Let me know if I can contribute in some way.

[Shadow]

Thank you very much, and happy new year

Do you have experience in building driver/dll files for Linux and Mac systems? If so that'd be very great, because I know shit about building stuff on platforms other than Windows^^"
I would love to have Linux and Mac ports as well, if you want to take that position and jump at that opportunity, why not of course.

Development will become more public and transparent as of this January - I'm finally coming out of my development dungeon lol. The SDK should be backed by a small sophisticated team from this year on.
There'll be a github board as well as general discussions here at our beloved ut99 forums.

[anth]

Noone (including Westlake/Epic/Loki/UTPG/OldUnreal) has ever released a macOS UT client that supports native mods. This is because all of the aforementioned companies/organizations released the macOS UT client as a statically linked binary that does not have the necessary functionality for dynamically binding to third-party mods.

As for native Linux mods: this is really easy. You should be able to figure this out using the README and CMakeLists.txt in the OldUnreal 469c SDK. It will, however, require a little bit of CMake hacking.

[The_Cowboy]

Hmm, let me see if I can cleverly find a way to build on Linux.
Off the top seems like Core.a could have been supplied just like the windows counterpart, Core.lib. Maybe linking with Core.so is the trick. I may have to experiment.

Was little finicky about the x86 libs on Linux, seems however, x86_64s work just fine!!
Kudos with the GitHub board, count me in!!

[The_Cowboy]

Linux (Ubuntu) status:

Ok on the bright side I am able to compile ChatDiamond.so on Ubuntu.

The thing that I thought to be easy, ChatDiamond.u compilation, is needing bit of trick.

Code: Select all

 ./ucc-bin make
WARNING: using preference directory: /home/the_cowboy/.utpg/System/
WARNING: Using system ini file: /home/the_cowboy/Unreal Tournament GOTY/System/UnrealTournament.ini
WARNING: Using user ini file: /home/the_cowboy/Unreal Tournament GOTY/System/User.ini
=======================================
ucc.exe: UnrealOS execution environment
Copyright 1999 Epic Games Inc
=======================================

--------------------Core--------------------
--------------------Engine--------------------
--------------------Editor--------------------
--------------------UWindow--------------------
--------------------Fire--------------------
--------------------IpDrv--------------------
--------------------UWeb--------------------
--------------------UBrowser--------------------
--------------------UnrealShare--------------------
--------------------UnrealI--------------------
--------------------UMenu--------------------
--------------------IpServer--------------------
--------------------Botpack--------------------
--------------------UTServerAdmin--------------------
--------------------UTMenu--------------------
--------------------UTBrowser--------------------
--------------------ChatDiamond--------------------
Analyzing...
Parsing CDDiscordActor
Parsing CDUTConsole
Parsing CDChatWindowHelperContextMenu
Parsing CDUTChatTextTextureAnimEmoteArea
Parsing CDEmoDisplayArea
Parsing CDUWindowCreditsControl
Parsing CDModMenuWindowFrame
Parsing CDAboutWindow
Parsing CDChatWindowChat
Parsing CDChatWindowEmojis
Parsing CDConfigurationWindow
Parsing CDUTConsoleWindow
Parsing CDClientSideWindow
Parsing CDMiniFrameList
Parsing CDModMenuItem
Parsing CDHash
Compiling CDDiscordActor
Compiling CDUTConsole
Compiling CDChatWindowHelperContextMenu
Compiling CDUTChatTextTextureAnimEmoteArea
Compiling CDEmoDisplayArea
The package you are trying to save calls function UWindow.UWindowDynamicTextArea.LMouseUp. This function was not present in UT v436, so this package will not work on UT v436 clients or servers. Do you want to call UWindow.UWindowWindow.LMouseUp instead to fix this compatibility problem? (Y/N): n
This package will not work on UT v436 clients or servers.
The package you are trying to save calls function UWindow.UWindowDynamicTextArea.LMouseDown. This function was not present in UT v436, so this package will not work on UT v436 clients or servers. Do you want to call UWindow.UWindowWindow.LMouseDown instead to fix this compatibility problem? (Y/N): n
This package will not work on UT v436 clients or servers.
Compiling CDUWindowCreditsControl
Compiling CDModMenuWindowFrame
Compiling CDAboutWindow
Compiling CDChatWindowChat
Compiling CDChatWindowEmojis
Compiling CDConfigurationWindow
Compiling CDUTConsoleWindow
Compiling CDClientSideWindow
Compiling CDMiniFrameList
Compiling CDModMenuItem
Compiling CDHash
Function ChatDiamond.CDEmoDisplayArea.LMouseDown has superfield UWindow.UWindowDynamicTextArea.LMouseDown.  This superfield was not present in UT v436, so this package will not work on UT v436 clients or servers. Do you want to use UWindow.UWindowWindow.LMouseDown as the superfield to fix this compatibility problem? (Y/N): n
This package will not work on UT v436 clients or servers.
Function ChatDiamond.CDEmoDisplayArea.LMouseUp has superfield UWindow.UWindowDynamicTextArea.LMouseUp.  This superfield was not present in UT v436, so this package will not work on UT v436 clients or servers. Do you want to use UWindow.UWindowWindow.LMouseUp as the superfield to fix this compatibility problem? (Y/N): n
This package will not work on UT v436 clients or servers.
The package you are trying to save imports Function UWindow.UWindowDynamicTextArea.Paint2 from package UWindow. This object was not present in UT v436, so this package will not work on UT v436 clients or servers. Are you sure you want to continue? (Y/N): y
Success - 0 error(s), 0 warnings

Either ucc-bin's make is still broken, last I remember bugging Ryan C Gordon about that, or I am missing something because ChatDiamond.u is not to be seen in System directory. Copying .u from windows compilation may be the route then?

A nice feature is the following prompt

which seems new and not present in Windows version.

[Deaod]

Passing the parameter "Silent" to ucc make is supposed to silence those messages, and automatically answer Yes to all suppressed questions (./ucc-bin make Silent).
Now ... whether you want to answer Yes to all of those questions is something you need to meditate on. If you do, you are no longer compatible with pre-v469 clients/servers.

[The_Cowboy]

Got even bigger issues with silent switch (not saying that is related )

Code: Select all

the_cowboy@quark:~/Unreal Tournament GOTY/System$ sudo ./ucc-bin make silent
WARNING: using preference directory: /root/.utpg/System/
WARNING: Using system ini file: /home/the_cowboy/Unreal Tournament GOTY/System/UnrealTournament.ini
WARNING: Using user ini file: /home/the_cowboy/Unreal Tournament GOTY/System/User.ini
=======================================
ucc.exe: UnrealOS execution environment
Copyright 1999 Epic Games Inc
=======================================

--------------------Core--------------------
--------------------Engine--------------------
--------------------Editor--------------------
--------------------UWindow--------------------
--------------------Fire--------------------
--------------------IpDrv--------------------
--------------------UWeb--------------------
--------------------UBrowser--------------------
--------------------UnrealShare--------------------
--------------------UnrealI--------------------
--------------------UMenu--------------------
--------------------IpServer--------------------
--------------------Botpack--------------------
--------------------UTServerAdmin--------------------
--------------------UTMenu--------------------
--------------------UTBrowser--------------------
--------------------ChatDiamond--------------------
terminate called after throwing an instance of 'wchar_t*'

Developer Backtrace:
[ 1]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(_Z12HandleSignali+0x222) [0x7ff59addd8c2]
[ 2]  /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7ff59aa0b520]
[ 3]  /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x12c) [0x7ff59aa5fa7c]
[ 4]  /lib/x86_64-linux-gnu/libc.so.6(raise+0x16) [0x7ff59aa0b476]
[ 5]  /lib/x86_64-linux-gnu/libc.so.6(abort+0xd3) [0x7ff59a9f17f3]
[ 6]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(+0x4a07b) [0x7ff59ad4607b]
[ 7]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(_ZN10__cxxabiv111__terminateEPFvvE+0x6) [0x7ff59adf31a6]
[ 8]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(+0xf7211) [0x7ff59adf3211]
[ 9]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(+0xf7364) [0x7ff59adf3364]
[10]  /home/the_cowboy/Unreal Tournament GOTY/System/Core.so(+0xbd2ef) [0x7ff59adb92ef]
[11]  ./ucc-bin() [0x4074b7]
[12]  ./ucc-bin() [0x406d63]
[13]  /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7ff59a9f2d90]
[14]  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7ff59a9f2e40]
[15]  ./ucc-bin() [0x4054aa]
Signal: SIGIOT [iot trap]
Aborting.

Signal: SIGIOT [iot trap]

History: (no backtrace available.)

Exiting due to error

---

Automatically merged

Success!


Few things to note:

• The uscript compiled binary is generated in /home/.utpg/System (yeah .utpg ). My mistake, should have seen the first line.

• If you don't delete the .u package, next compile is gonna crash with the message shown previously.

I am now versed with multiplatform native support for UT mods, except MacOS for which, ahem, seems no one has practical answer!