Split: 227 technical discussion

[Draco Nihil]

Disturbingly enough the Octree/FCollisionHash crash bug even exists in UT200x and I think also UT3.

While I can see 227 came a long way in terms of bug fixes, the stuttering problem I experience I KNOW has something to do with the compiler, because when taking UTGLR and compiling it for 226b I end up with the same problem... Hell building the sources for UTGLR just for UT436 makes UT436 have the stuttering issue then. I've had this happen on old catalyst drivers, new catalyst drivers and right now I'm on 13.1 since it's the last driver that didn't horribly break backwards compatibility with D3D6-7 while still making every other game, old and modern, run at solid performance.

In regards to the features, I would of appreciated it if they were in a OldUnreal.U OldUnreal.DLL package rather than merging them into UnrealI and UnrealShare. When dealing with engine features there's no avoiding the modification of Core and Engine, but I strongly dislike the modification of the original Unreal packages. This might sound like a oxymoron considering I made a "patch" for UBrowser console for 225f clients, but that merely changed a single actor and didn't add or change anything else in particular.

Even in the event of system conform, there's still a chance someone might opening up a map that has Woodruff or something or other, and non 227 clients get a "Cant find file in package" error even if the server is set to allow old clients. While not on the same level of severity, the Unreal Anthology is a good example of that mistake.

There's also this rather humorous situation I had in Delacroix's server where he was using the 227 quadshot and I was connected using 225f... The result? My client loads the "broken unfinished" quadshot while on the server and to other 227 clients connected, everything is normal. How this only results in client-server discrepancy and not a GPF astounds me.

I also, personally do not see any reason for 227 to have static mesh support. To me that just takes the fun and labour of love involved with Unreal 1 map making and almost entirely tosses it aside. While the BSP system is obviously antiquated and hard to work with, it's overcoming these hardships that really makes map making a magical process.

[ividyon]

As I've already stated in other settings, I definitely agree that some of 227's new features have been implemented poorly. These features include:

• Bleeding damage
• Woodruff
• MiniGunSentry
• UTranslocator
• TeleAmmo

It's beyond me how any of these things could be implemented as classes in core engine packages. I can somewhat understand Woodruff in that it's an "author's license" luxury, a result of Smirftsch enjoying Waldmeister and deciding to put it into the game as a small 227 easter egg. But all the other stuff? Random low-quality Unreal beta items and an entirely new health sub-system that has no place in the original game? How is this NOT a mutator in a separate .u? What is it doing in Game Settings?

And even Woodruff, while tolerable, is a mistake, because it will prompt newbie mapmakers to implement Waldmeister on Na Pali, leading to all sort of weird mapping choices and logical discrepancies (as well as looking sorely out of place next to other vanilla game meshes like the Nali Healing Fruit, because the art style is entirely different). This and the other classes I listed above are intrusions into the game's original vision and 227's identity as a game patch rather than a content/expansion pack.

However, regarding the other new features 227 brings...

I also, personally do not see any reason for 227 to have static mesh support. To me that just takes the fun and labour of love involved with Unreal 1 map making and almost entirely tosses it aside. While the BSP system is obviously antiquated and hard to work with, it's overcoming these hardships that really makes map making a magical process.

One of 227's roles has been improving the engine and it's editing tools and adding various new possibilities for map makers to vastly expand what they can do with the engine, and that's totally fine.

Static meshes, skeletal meshes, bone animation functions, new lighting systems, particles, dynamic shadows, environment map overlays, Distance Fog, dynamic zones, new trigger types, WaterSurfaceInfo etc etc. These are all new features and tools that allow modders to breathe new life into the game and create their own custom content. That is the difference to the stuff I've described above, which is forced insertion of existing mods/custom content into core game files.

[Teflon]

Has anyone actually used the Unreal early 98 beta stuff in 227? It seems to me it was added for the sake of "restoring" beta content and not what would actually be useful for modders. I'm a huge Unreal beta buff, but even I know that putting that shit directly into Unrealshare and Unreali is stupid. It should've been put in separate files so that the original files would be untouched. It's not like this is unprecedented in FPS games; Doom source ports wisely put their resources in a separate file instead of trying to jam it all into Doom/Doom2.wad. The later versions of 227 have things like the original weapon sounds as mutators instead of trying to integrate them into the game's sound files; why can't you do this with the random beta shit?

[ebd]

I also, personally do not see any reason for 227 to have static mesh support. To me that just takes the fun and labour of love involved with Unreal 1 map making and almost entirely tosses it aside. While the BSP system is obviously antiquated and hard to work with, it's overcoming these hardships that really makes map making a magical process.

As challenging as it is to "overcome the hardships of BSP," static meshes are a 1000 times more work to get right I assure you, especially since there are no preexisting meshes like in UT2003 or UT2004. Even if there were, they had their challenges which level designers would face. True, noob mappers could slap some meshes together and call it done, much in the way that mappers could slap some cubes in and call it done, but neither method produces very good levels.

227's static mesh system is a godsend for fine detail and for reducing node & vertex count, but to use them extensively would be waaaaaaaaaaaay too much work. I think a lot of people who irrationally hate static meshes don't realize that.

[Tarydax]

To me that just takes the fun and labour of love involved with Unreal 1 map making and almost entirely tosses it aside. While the BSP system is obviously antiquated and hard to work with, it's overcoming these hardships that really makes map making a magical process.

Static meshes aren't stopping anyone from using the BSP system. As a mapper, wrestling with the BSP is by far my least favorite part of mapping. I find mapping a lot more fun when something I make isn't plagued by all kinds of BSP holes, which doesn't happen very often.

I agree with ebd. The lack of preexisting meshes means that you either have to make your own (which is extremely time consuming) or convert them from other games (which can also be time consuming, plus you have to deal with conflicting themes). I don't use static meshes mainly because it would take me way too long to use them correctly; it would probably take less time just to go with all BSP.

[Mister_Prophet]

I'll go out on a limb and say that what I think Draco is talking about is preserving the sort of "feel" you get from playing Unreal at its purest element, not so much a real criticism of static meshes in general. I understand both sides of this, as a level designer and as someone whose worked on projects that could be accused, perhaps, of drifting away from the core integrities of Unreal by exploring avenues like post processing implementation, advanced particle effects, and stuff. My stance on static meshes is that I know how hard it is to make them, let alone implement them well enough for the player's immersion factor. People are quick to denounce CGI in movies and assume it's somehow easier than using animatronics and makeup, but the truth is that it is very difficult, just as time consuming, and expensive.

The challenge mappers who use SMs for 227-only levels, as I see it, is keeping the immersion as constant as BSP is. That's all, but it is a big issue and not one to be taken lightly. I like that there are massive visual modifications out there for games like DOOM2, but I would be aghast at seeing a 3d modeled cacodemon in place of a sprite. That's kind of how Unrealites are about static meshes sometimes. I think there's a point where you have to decide if you are okay with Unreal being Unreal or if the game as it is has gotten stale for you. Maybe Draco's concerns are more about what he's worried some people might do to his game and making it a trend more than what toolsets the 227 patch provides.

[Draco Nihil]

Improving the editor, yes that's like... a big leap forward because Visual Basic is horrible and I have no idea why Sweeny wrote the editor in VBasic instead of C++ like the client and the engine itself.

The BSP node builder is probably the one thing that needs serious polishing though when you think about how horrible the BSP system itself is, the rendering pathway shouldn't rely on BSP occlusion and perform something more GPU leveled like true Hardware T&L. How that could go about getting implemented without ruining the look and feel of Unreal's levels I dunno', but that would still offer quite a performance boost over the CPU processed BSP and lighting occlusion and the problem with "BSP Holes" would go away.

And yes Mister Prophet does understand the point I'm trying to make here in regards to my feelings of extra effects and static mesh support being used in maps.

And ividyon, hahaha, yeah you know I originally made the bleeding mutator. Shivaxi asked me for the code, I gave it to him, then somehow that ended up getting into 227, I was then asked to make green blood decals, did that and submitted it. I was so not caring of my code for that that I didn't even care about being given actual credit. The system would require playerpawn related code to work properly anyways, the method it used then (possibly now too) is seriously flawed as it relied on actors being spawned and owned by the damaged pawn to handle the bleeding system, the actors destroying once the bleeding stopped. (and then bad shit happens when the pawn dies, because I wasn't really that bright then)

It's worth mentioning all I did to make the green blood decals was shift the RGB channels around so the reds turned to greens, a very very trivial operation. Hence why I didn't mind doing that though Operation Na Pali (or wait did OldSkool have it originally?) probably did the same thing to produce said decals.

One of my other largest concerns but I've always been fearful of stating this due to possible hostile repercussion; is the whole integrity of the codebase of the 227 patch. Overtime I had the inking feeling it was becoming a spaghetti as .:..: provided tons and tons of features and Smirftsch was probably buried underneath all that. I also still wonder how most of the engine related code came from like the Octree collision and of course the static mesh code itself. Wasn't there a incident where someone from Epic Games contacted Smirftsch (or posted in the forums I don't remember) wanting a explanation for how 227 introduced all the features in the first place?


Also, I don't understand the whole complexity of staticmeshes. If you have blender (or lightwave or 3dstudio max) you can make a static mesh, and obviously a 3D editing tool is WAY beyond better than working with UnrealEd's brush system and vertex editing. Though when I look at various level design documentation, I've heard that people used 3DSMax for Unreal level design (designing the brushwork that gets imported into Unreal)... If this is true then man, I need to get into that some day since all I've been doing is strictly primitive work.

[Mister_Prophet]

Also, I don't understand the whole complexity of staticmeshes. If you have blender (or lightwave or 3dstudio max) you can make a static mesh, and obviously a 3D editing tool is WAY beyond better than working with UnrealEd's brush system and vertex editing. Though when I look at various level design documentation, I've heard that people used 3DSMax for Unreal level design (designing the brushwork that gets imported into Unreal)... If this is true then man, I need to get into that some day since all I've been doing is strictly primitive work.

Xidia Gold is a good example of BSP made in 3DSMax and imported. The terrain in the fourth level for instance (the mine caves) was made in Max and so was the terrain used in the frozen Skaarj level. I've used Silo and other programs myself for parts of RD, but I personally feel more comfortable using vertex editing for bsp terrain.

In terms of static meshes doing the same job, the problem as I see it is half making the stuff and half adding it in a way where old school Unreal players won't notice they are looking at Static Meshes, which frankly is hard to do the more complex your static meshes are. Architecture is easier but terrain almost always looks "too good" for Uengine1, if that's possible somehow. Kudos to those that can convince

[Smirftsch]

Sorry for delay, had a busy day, needed to set up my new PC etc etc.
I'm seriously surprised how positively this topic became, I owe someone here a beer for a good advice (komm mal rüber wenn du zeit hast ).

Ok, back to topic.
Some of the includes which came into UnrealI and UnrealShare surely could have been placed into a new package, some stuff in Engine simply must be in Engine, but there are also things which could or even should be in a separate .u file, agreed.
Now, afterwards I give it an 100% chance that I would have done so if I would have known where this all leads to. At first it was small addition here, filling up a missing thing there and fixing a bug here and there.
Now please don't think that the stuff added was an arbitrary process, all things have been requested one way or another and seemed to be either a very good extension to the existing game in matters of "things that should have been there in the first place" or simply to have proper replacements for already existing but bugged classes which were beyond any repair if not willing to break all compatibility directly. And compatibility is and was one of the most wanted "features" - I can't count how many hours we spent additionally to fix things while keeping older maps/mods and server/client relations intact.
Afterwards everybody is wiser, this surely counts for me as well, but to change it now again would only create more hacks, more messy code and more people getting confused. It's no option anymore as it would make things only worse.
On the other hand, despite the feeling of some people that I did blasphemy by touching the original packages and it would surely have been better design wise, I see little to no real technical disadvantages of that, even if I would have done in a separate package- it would have become a "core engine" package as well, necessarily, bound in as strictly as the other packages because many of the 227 things also depend on native parts- and if leaving those out to have an fully optional package (something surely possible for some if not all the here mentioned classes but definitely only a part of all the extensions in question)...well but then we are again almost where we are now...
It may would have helped to separate things easier, but that's it, so the package is not optional but the functions are. Other than that it only adds some KB to the existing packages with no speed disadvantage. And about the "poor" implementation - it's uscript, open and free to work on for everybody, send/suggest me improvements

Yes, there are some things which have been mentioned and criticized a few times like the Quadshot, but seriously if it would have been your decision, would you really have kept in the broken quadshot, then maybe subclass it and fix the subclass just because of an ancient, rarely used weapon mod with a few lines of code?
It's only one example, but a very good one, very representative for a lot of similar situations. Would you want to have a patch full of messy hacks and workarounds instead of fixing the root of it? Really? We already made hundreds of "sidesteps" to keep old mods intact and to keep chances low that such things happen.
So this may have rendered stuff like "OldQuadshot" unusable, a package I made 2001 or something, but it should be easy to fix this up in a few minutes for anyone with Uscript experience. So yes, it causes some mods to freak out, for example those, which used hacks to work around old bugs, but those mods are rare and most of it still can be fixed quickly, if willing to.

While I can see 227 came a long way in terms of bug fixes, the stuttering problem I experience I KNOW has something to do with the compiler, because when taking UTGLR and compiling it for 226b I end up with the same problem... Hell building the sources for UTGLR just for UT436 makes UT436 have the stuttering issue then. I've had this happen on old catalyst drivers, new catalyst drivers and right now I'm on 13.1 since it's the last driver that didn't horribly break backwards compatibility with D3D6-7 while still making every other game, old and modern, run at solid performance.

Can't say, really. For most people out there it seems to work out fine and I refuse to assume that there is a problem in general with VC2008- thousands of apps in the net compiled with it clearly show that.
However, if taking a VC2008 build of D3D9 and old 226b code, I think there are indeed chances of problems, but for 227 everything is built with VC2008, so this one is ruled out already. Maybe it's something specific with the hardware, with the OS, with your Directx- many possible things come to mind and it's really hard to track down. Again don't get me wrong here, I don't say its your fault or that it wouldn't happen for you and it is also really possible it has something to do with compiler, but still there are many other reasons possible and it seems to be some rather unique problem -judged by the number of existing (or in this case non existing) comparable reports.

The BSP node builder is probably the one thing that needs serious polishing though when you think about how horrible the BSP system itself is, the rendering pathway shouldn't rely on BSP occlusion and perform something more GPU leveled like true Hardware T&L. How that could go about getting implemented without ruining the look and feel of Unreal's levels I dunno', but that would still offer quite a performance boost over the CPU processed BSP and lighting occlusion and the problem with "BSP Holes" would go away.

As said we spent quite some time and there have been quite a lot of fixes and improvement in this matter

And ividyon, hahaha, yeah you know I originally made the bleeding mutator. Shivaxi asked me for the code, I gave it to him, then somehow that ended up getting into 227, I was then asked to make green blood decals, did that and submitted it. I was so not caring of my code for that that I didn't even care about being given actual credit. The system would require playerpawn related code to work properly anyways, the method it used then (possibly now too) is seriously flawed as it relied on actors being spawned and owned by the damaged pawn to handle the bleeding system, the actors destroying once the bleeding stopped. (and then bad shit happens when the pawn dies, because I wasn't really that bright then)

I was given it by Casey, a long time I didn't even know about your involvement (or forgot it, if he said so) ^^ - yet I find its a very very nice addition for realistic campaigns.

One of my other largest concerns but I've always been fearful of stating this due to possible hostile repercussion; is the whole integrity of the codebase of the 227 patch. Overtime I had the inking feeling it was becoming a spaghetti as .:..: provided tons and tons of features and Smirftsch was probably buried underneath all that. I also still wonder how most of the engine related code came from like the Octree collision and of course the static mesh code itself. Wasn't there a incident where someone from Epic Games contacted Smirftsch (or posted in the forums I don't remember) wanting a explanation for how 227 introduced all the features in the first place?

I know I'm only a decent (but persistent!!!) coder and no genius like other people. Dots is surely a very talented and gifted person in these matters while drainbamaged me always has to work out all things the hard way, yet this is some aspect which I can't follow. Any code goes through my hands and although I have to give up on the maths and equations for all the mesh stuff (its plain not my world) I still have an overview over all things going on and you are talking like there have been only additions from dots which is plain not the case. Surely he contributed many things, especially when it comes to the new features while I often stuck with working out fixes for bugs and debugging all stuff, but I fail to see how this should or could bury me in some way. Granted, during my chemo treatment I had a very hard time memorizing things and even today I have to re-read a lot of stuff again again again and again (did I say again?), but I keep track on any change and I also have some kind of versioning system which helps me to keep overview- how else do you think this should work?
And no, Epic never asked me that, why should they? I never gave any code out and they didn't contact me since 2005 or something- and if I wanted to know something or asking about things like UT I always got an answer like "We don't have the bandwidth for....<put whatever in here>".


---

As a side note for StaticMeshes and the difficulty to create them- since there is the ability to import .obj files there are big resources in the web, not only from other UEngine games.

---
PS: Maybe 227j will be the last version, maybe not depending on eventually found bugs again, but in any case the times of fixing severe bugs and adding huge additions are very much over. I'm tired and if I would only do the things yet I really want to I'd probably stick for the moment just with OpenGL3/4 and working on OpenAL improvements and bugfixes if necessary. Bugfixing can be very funny but it can be also extremely annoying.
We added some nice native stuff yet for 227j, like support for multithreading when it comes to independently running stuff from fire and it also comes with a new OpenAL as said already, I found the reason for "bsp occlusion crashes" and "UED crashing while building huge spheres crashes" and although it can't be fixed 100% it's way more stable now. I cleaned up a lot of code and especially the Linux port needed some updates yet. There is a Linux ARM port now, to run a server on a Pandaboard with power consumption of not even 20W f.e.
Then again many more small things, but its very close to 227i yet and quite a few of the people taking part here still participate in testing ( in theory at least) so they could have a look any time - although the feedback is extremely low to non existent in the last months, so maybe I should take the opportunity now to act some critics as well here: If I get feedback in the first place there is no need to complain afterwards.

[[UDHQ]Jackrabbit]

@Smirftsch: So many people agree here that a bad hole has been dug with the Unreali and UnrealShare packages that many users (especially on this forum) find ugly and a depart from the original mother game we know. You say that it would be adding more hacks to fix it, but I say its as easy as one line of code and a simple array built into a separate package like "UBetaContent.u" or something. You could just as easily remove *ALL* added 227 content from to the UnrealShare and Unreali packages, add them to their corresponding new custom .u packages (which could even be an optional download on OldUnreal) and mask the packages names in an array:

Code: Select all

var String RmUnrealiPackageList[x]
var String RmUnrealSharePackageList[x]
RmUnrealiPackageList[0]="UBetaContent"
RmUnrealSharePackageList[0]="UBetaContent"


and then parse these "special packages" in core 227 with:

Code: Select all

psudocode in PreBeginPlay:

   s=Left(String(clients server packages),11);
   
   if(s ~= "UBetaContent")
           add here a [i]package mask[/i] to the Unreali/UnrealShare packages for every actor currently in the map using UBetaContent


This is some relatively simple code which is non-intrusive and just adds a "mask exception" for those maps which use the 227's Unreali and UnrealShare beta content. Even better is the fact all of this could be done in the "UBetaContent package" itself so if its not in serverpackages none of this code would execute on 227 by default. Whether or not this package UBetaContent would go into 227 serverpackages by default would be up to the 227 dev team, but it would always keep compatibility with the previous 227 Unreali and UnrealShare packages and not break maps that use that beta content.

[Smirftsch]

This might be true for the beta content specifically and is for this indeed worth the consideration but definitely not for all 227 content in there which can have a lot of bindings and dependencies, a can of worms I don't want to open for already mentioned reasons.

[[UDHQ]Jackrabbit]

Also another completely bogus addition I found in UnrealShare which is NOT beta content but should get included in the UnrealShare mask is the "UnrealShare.ArbitItem".

I can see exactly why you would consider this item so important for DM mappers to include it in the patch but a assure you that putting it in UnrealShare was an absolutely terrible idea. Including it in a 227Extras.u package would make so much more sense simply due to the fact that mapmakers who want to use this ArbitItem for their maps (which I would use quite honestly), could maintain backwards compatibility with their maps that use this item instead of getting a "can't find file for package UnrealShare.ArbitItem"

common sense?

[Smirftsch]

And you will definitely find more of these, but this won't work out for everything. So, again: a can of worms I don't want to open for already mentioned and obvious reasons. Common sense?

[ividyon]

common sense?

Please leave out these unnecessary stingers; the discussion's been going well so far.

As for ArbitItem, I deliberately left that out of my list of items I disagree with, because it does serve a purpose as a mapmaking tool, rather than being a piece of content that sticks out like a sore thumb. I also fail to understand your reasoning in how using ArbitItem in a separate package would allow to maintain backwards compatibility if this proposed 227Extras.u was a package that relies on 227, and would have to be used in the map to make use of that actor. Plus, if somebody uses 227 to map and therein uses ArbitItem, chances are they're also using one of the many other new features in their map, anyway.

I'm also wondering why people want 227 content to be backwards compatible so badly. The issue and "can of worms" with these out-of-place classes in the core Unreal packages is that, if they were to be removed now, a bunch of in-development maps could break and require tedious fixing. Removing them from Unreali/UnrealShare is not a matter of enabling backwards compatibility (which is something completely superfluous and undesired given the massive amount of other awesome 227-only features that mapmakers can use), but a matter of proper coding etiquette and the maintaining of the game's identity. These things have been violated by those classes, and Smirftsch acknowledges this, but I'd agree that the problems with removing the classes would outweigh the benefits.

[[UDHQ]Jackrabbit]

I'm also wondering why people want 227 content to be backwards compatible so badly.

I couldn't care less about the 227 client being backwards compatible personally. I make my argument of items like ArbitItem because these are items that can be placed on normal custom DM maps by anyone that run the server. Think about this situation:

Person X makes his deathmatch map in 227's editor and wants his map to work in all versions (or at least the most popular Unreal versions). Person X fiddles with ArbitItem and puts it in his map not knowing this isn't considered "stock unreal content" because its placed in UnrealShare.u. Person X just made his map with one fell swoop reject ALL OTHER CLIENTS other than 227 clients (bAllowOldClients true or false doesn't matter now).

I ask both of you, Is this really the functionality that is meant for Mappers new or old that use the latest game patch? Its completely unfair to assume that they know ArbitItem is NOT STOCK CONTENT shipped with Unreal.

Seriously, I wasn't try to be derogative with the common sense statement people... this IS freaking common sense!!

EDIT: Might I also add to sana's argument in regards to "227Extras.u". Yes, you are right that 227 dependent mods could also be included in that package making it incompatible with versions other than 227. My example here, ArbitItem is not one of them. This is a Pickup item that could be recompiled in any other version of Unreal and from what I read in the comments by TCP Wolf, it has even been tested for every other Unreal version including 224. So why not make two packages? uExtras.u and u227Extras.u or something like that to separate the classes which can be used by a mapper for all versions and ones that can only be used on 227 clients.