Unreal Tournament Community SDK is an open source engine fork of the Unreal Engine 1.x with a modern development framework for Unreal Tournament. A thousand delays later we hit rock bottom and infinite possibilites at the same time with this community-propelled engine fork for one of the greatest 3D games of all time. We will never forget nor forgive what Epic Games did on the 14th December 2022.

Post news Report RSS UTSDK February 2023 Release Statement

We all waited for that February Release, yes. After thousands of problems with UT 469c later I'm way more frustrated yet a bit wiser than before. Its almost impossible to load UTSDK's Engine - UT 469c has major issues with expanding its own code base. Its still not possible to extend it with own render devices. There's one major issue here: The (possibly changed) UCC compiler seems to force that almost every C++ class needs to have an UScript equivalent, which wasnt necessary with UT 436.

Posted by on

We all waited for that February Release, yes. After thousands of problems with UT 469c later I'm way more frustrated yet a bit wiser than before. Its almost impossible to load UTSDK's Engine in the Unreal Editor - UT 469c has major issues with expanding its own code base. Its still not possible to extend it with own render devices. There's one major issue here: The (possibly changed) UCC compiler seems to force that almost every C++ class needs to have an UScript equivalent, which wasnt necessary with UT 436.

I tried to compile 469c's Engine (UScript class code base) with RenderDevice, RenderDeviceOldUnreal469, Subsystem etc included as UScript classes, so that in turn I can subclass it with sdkRenderInterface. Also UT 469c's UScript source isnt clean and the Textures needed to be exported in order to rebuild Engine.u. I'm now completely exhausted from all these obstacles. And now the Editor Engine isnt loading, after I "solved" that UScript class issue.

sm render visualfinal[Screenshot of a 2021 build with a Static Mesh running in UT 436's Unreal Editor]


The SDK is ready so far for testing, but with all these problems with UT 469c I doubt a release within the next days. You cant even use own Render Devices anymore. This is so insane. Seems like I have to program an own render pipeline, because I'm totally sick and tired of this. SO since I promised more open communication, this is the current state of the release. What a crime story, really. For reference, and for at least releasing something I uploaded the Source here at Moddb. I also decided to deploy the SDK with multiple Sub Engines, because one large Engine package leads to too many problems right now (especially with debugging / problem analytics).

Bild 2023 03 01 014701773

I will now use a different exemplary feature, that is easy to implement, like Timers. Yes, this might be lovable compared to Static Meshes, but for now coding an own Render Device based on URenderDeviceOldUnreal469 is impossible.

There will be a new release date with an overhauled structure and without the old render pipeline end of March. Please understand that this restructuring takes some more time, but allows me to analyse problems with UT 469c way better. For now this is a Source-only release.

Post comment Comments
Feralidragon
Feralidragon - - 246 comments

Instead of ranting about how v469 doesn't meet your needs or that something is broken in some capacity, have you tried to maybe actually reaching out to the v469 devs?

Because I am in the OldUnreal discord almost every day, here:
Discord.gg
and I haven't seen you reach out even ONCE to the v469 team about these problems you're apparently having yourself alone, and only you alone.

Not even in GitHub apparently:
Github.com

We've had plenty of people adding more native extensions of their own to v469 in the meanwhile, including a brand new Vulkan renderer from someone outside of the team (same as you), and they haven't had all these problems, and the few problems they had they actually got it sorted out with the v469 devs, and fairly easily at that.

And we're talking about a patch that had 3 "official" releases thus far, with plenty of RC and preview releases in the middle to properly and fully validate the patches themselves, with a large chunk of the community testing them and providing valuable feedback about everything, and with a constant focus in trying to not break anything.

And yes, v469 is of course going to be different from v436 in many ways, especially natively, although I strongly suspect not exactly in the ways you're portraying here, and that's why it's important to reach out to them and discuss these things properly, in order for you to actually understand what's going on, and so that if something is actually broken, they are given the opportunity to reproduce the issue and fix it, which they are generally fairly fast to do, even faster than it would be reasonable expected from a team composed by people with busy lives of their own.

From there, maybe you could have some valid constructive criticism to offer, but this is certainly NOT what you're doing here, because right now all you're doing is venting your frustration and acting completely in bad faith against the team that put v469 together, and consequently also against the very community that helped doing so and towards whom you're supposedly trying to release this SDK for.

So please think for a moment what you're actually doing, because you're only making it harder for yourself, needlessly.

Reply Good karma Bad karma+2 votes
UT99_Shadow Author
UT99_Shadow - - 388 comments

Not ranting, just saying how it is. You misunderstood me. I really want to use 469c as a code basis and I appreciate all their work and effort.

I'm just really having a hard time trying to do so. I was communicating these issues already in the past per E-Mail, and was said to wait for the Source SDK. Also I had opened a bug case at github in the past. You're admitting yourself that its difficult natively too, but blaming me I'm ranting against 469 and not communicating with them? You didnt know about the E-Mail comm and the github case. These problems are my problems, I'm NOT passing the bucket to the 469 team. I'm sorry if you took that the wrong way (or someone else).

AGAIN: I want AND appreciate 469 as standard code base. Didnt I make that clear with at least the last sentence "to analyse problems with UT 469c way better"? At which part was I ranting against 469? I'm glad this patch exists. I just have major difficulties porting my engine to 469 and expressed that. I didnt say "469 is complete garbage". I would never do that.

Reply Good karma+2 votes
Feralidragon
Feralidragon - - 246 comments

No matter how you paint it, it is ranting.

Maybe this isn't exactly how you wanted to write it, and maybe it was the build up of frustration you were feeling at the time, but regardless, there's no misunderstanding here (and you're distorting a lot of what I said, by the way, but I am not even going to cover that).

I mean:
>>> "After thousands of problems with UT 469c later I'm way more frustrated yet a bit wiser than before. Its almost impossible to load UTSDK's Engine - UT 469c has major issues with expanding its own code base."

who reads that and interprets it as just being an informative report on the situation, and as something being YOUR problem alone?

----

Either way, moving on, they are going to actively try to help you out to solve these things and validate the problems you're seeing, and maybe hopefully you will get these things sorted out, although it should have been the other way around, with you coming to Discord and sort it out beforehand.

As for what I know and don't know about this whole thing: I know a LOT more than you think, and I know you reported some problems and were waiting for the native SDK, but you didn't really try to sort anything out after that, did you?

And that's the whole point here, really.

If your reasoning is because you consider this to be your own problem and not wanting to burden them with it, that's commendable of course, and I understand that, but the problem with that is that's in direct opposition of what you said early on in your article.

So, again, please think a bit better how to approach these kinds of things.

You're obviously more than smart and skilled enough to build an SDK like this to begin with, so performing basic development tasks like actual communication with the relevant people to seek information and solve problems like this shouldn't be this hard, it's the bread and butter of good software development.

No one is saying for you to have the v469 team to solve the bugs for you, but you should at least validate and update your own knowledge about how v469 is structured, and that's achieved by actually going there and make questions and validate your own understanding of things.

Doing things exclusively your own way, on top of inaccurate assumptions without any real attempt of validating the information, can only go all sorts of wrong, and then of course will only delay the release and just be a source of frustration for you, maybe to the point where you may just go on another 10-year hiatus, and there's simply no need for that at all.

Reply Good karma Bad karma+1 vote
SnowySilver
SnowySilver - - 5 comments

I sent an Invite to the discord in question on discord Shadow. I mentioned some of your rendering issues to Higor(Cacofff) He's just waiting for you to message him on discord about it. The dev team really wants to get to know your project so they can help you sort out any issues you have with what they've chanced.

Reply Good karma Bad karma+1 vote
watnouweer
watnouweer - - 1 comments

im curious what this exactly is and how you guys make this, do you guys have acces to the source code of the engine? im not even skilled enough to make a full functioning level, very impressive it seems.

Reply Good karma Bad karma+1 vote
Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: