Scout-kun is a lie... right?

Split: 227 technical discussion

For gameplay advice and broader discussion of single-player Unreal including custom maps, mods and mutations that alter the game.

Moderators: Semfry, ividyon

User avatar Draco Nihil
Skaarj Lord Skaarj Lord
Posts: 197
Joined: 06 Jun 2012, 21:18
Location: Independence, Kansas
Contact:

Subject: Split: 227 technical discussion

Post Posted: 08 Apr 2014, 02:51

ebd wrote:A very vocal minority harbors a lot of ire for this patch but they don't seem to have any specific reasons for it..

Tl;dr: use 227 at your own risk, stick with 226b if you want something that will work 100% of the time. For UT99, OldSkool can present rather frustrating issues, see below my 227 rant.

[spoiler]I feel I should clarify a few "specific reasons" that I have problems with the 227 patch.

It mostly has to do with the fact, well coming from my honest and non biased point of view: 227 bloated Unreal with alot of superfluous features that should of been kept separate of the primary engine and UnrealI\UnrealShare packages (i.e. should of been a MOD, not FEATURES), 227 is also compiled with newer Visual Studio compilers often producing binaries that execute very oddly on various machines due to retarded compiler optimization bugs and also 227 broke compatibility with Windows 4.x versions for no real good reason...
(No I don't believe there was ever a point to using the "Latest and greatest" Visual Studio when 2005 would of been sufficient especially for such a old game that people like me continue to play happily on Windows 98SE machines)

Another "FUN feature" of newer Visual Studio compilers is that Microshaft adds yet another stupid "Visual Studio C++ Runtime" library that your program is arbitrarily forced to use and unless you wade through the hell of configuring it to statically compile your binary with it, you either have to include the library with your distribution or point the end user to Microsoft's website for installing the redistributables... What exactly was wrong with just plain old mscvrt.dll?

227 is also bogged down with ridiculous "security features", such as constantly calculating SHA-1024 hashes of every single file on your machine and silently kicking you for executing commands too quickly or too many at once. (You know it would of been better and nicer if on the server side you simply just dropped the incoming packets rather than boot the client, like how one can configure Nepthyst to do in such a situation like that) You also cannot use EditActor online anymore which makes debugging replication problems very difficult as well.

It also makes it difficult to debug runaway scripts as 227 will simply cause the script to terminate rather than generate a Critical. (I'm not sure if there was ever a bool to toggle the default behavior back on as I am banned from OldUnreal for obvious reasons)

In all honesty I would of wished that 227 focused purely on fixing bugs and compatibility issues rather than INTRODUCE compatibility issues. (from the result of people clinging to these new "features" saying it's paramount to their mod\mappack)

It's ultimately up to OP if they want to use 227 or not, but honestly if you happen to be rocking voodoo class accelerators, just stay with 225f. Otherwise go with 226b and use either the old OldUnreal multimedia patch OpenGL's (not the newer one as it somehow inherited the weird performance issue bug 227 itself has) or kentie's d3d10drv.

If you use 225f I can provide a UBrowser.u replacement that has a windowed console with various bug fixes so that you avoid crashes that the dropdown console has. (It is a conformed UBrowser.u, so you wont get mismatches online, of course you will potentially get autobanned from nanny state servers thinking it's a "cheat")

I still and with great pride design my mods and maps with 224v. I don't care about the "new and exciting features" of the 227 unoffical patch. I never welcomed such features and given the amount of problems and inhospitality I was given towards my grievances with the patch's issues on my machine, I've refused to touch that patch even with a ten foot pole.

And that ends my rant for today.[/spoiler]

I should also mention, Unreal Tournament Co-op or rather just online play in general with OldSkool and some other mods, has had this ongoing bug where the ENTIRE player's inventory chain will just break entirely. In a co-op setting this is incredibly undesirable as it makes using your inventory virtually impossible and depending where the chain broke you will not beable to use your Translator anymore. The breaking happens very randomly as well. OldSkool is a very poorly programmed framework for Unreal Tournament single player and I often recall running into problems just having Operation Na Pali, Xidia:Gold and Skytown Reduxx all in the same install. (Crashes and what not)

There seems to be VERY few mappacks on file here at UnrealSP that require UPak, so obviously you would need either 226b (Unreal Gold) or the UPak from the standalone retail version of RTNP in order to play such maps. Keep in mind that the UnrealGold and standalone UPak's are ENTIRELY different packages but while they are conformed to one another to avoid online mismatches the standalone version contains EXTRA data that the UnrealGold version does NOT have. But to my knowledge there is not anything that touches said data as Unreal Gold's UPak was the most prevalent one.
“I am the dragon without a name...”

User avatar Delacroix
Skaarj Warlord Skaarj Warlord
Posts: 873
Joined: 21 Dec 2007, 17:22
Location: Poland.ut3

Subject: Re: Please help a newbie: custom maps and engine question

Post Posted: 08 Apr 2014, 14:28

[spoiler]
Draco Nihil wrote:I feel I should clarify a few "specific reasons" that I have problems with the 227 patch.

It mostly has to do with the fact, well coming from my honest and non biased point of view: 227 bloated Unreal with alot of superfluous features that should of been kept separate of the primary engine and UnrealI\UnrealShare packages (i.e. should of been a MOD, not FEATURES)


As far as Quadshot goes, I agree with that point of view - many mods USED ACTIVELY BY SOME PACKS are broken on auto by the patch's installation and they need to be fixed. Some have been already, so this is more of a song of the past rather than actual present trouble, but even still, that tells a story of its own.

However as far as Static Meshes and other stuff goes, well, I'll be blunt: many of that required core engine modification to even implement, I believe - so separating it as a mod/feature pack/sdk isn't a realistic goal. I'll leave more specifics to Smirftsch, as I don't know jacksquat about the code, and I never had access to anything more recent than 220 code to begin with.

Draco Nihil wrote:227 is also compiled with newer Visual Studio compilers often producing binaries that execute very oddly on various machines due to retarded compiler optimization bugs and also 227 broke compatibility with Windows 4.x versions for no real good reason...
(No I don't believe there was ever a point to using the "Latest and greatest" Visual Studio when 2005 would of been sufficient especially for such a old game that people like me continue to play happily on Windows 98SE machines)


What you don't seem to realize is that compiling 227 code - as per Smirftsch's explanation of the matter - became at one point too troublesome to be worth it, so using more recent VS, that solved most of these issues, was a natural consequence. Okay, so Win95 and Win98SE compatibility said bye bye. That's the price for progress.

Also, nowadays even Windows XP is left without Microsoft's official support, let alone ancient products like Win95 and Win98. You don't use 227 at your own risk, you use unsupported, obsolete operating systems and obsolete hardware at your own risk.

Another "FUN feature" of newer Visual Studio compilers is that Microshaft adds yet another stupid "Visual Studio C++ Runtime" library that your program is arbitrarily forced to use and unless you wade through the hell of configuring it to statically compile your binary with it, you either have to include the library with your distribution or point the end user to Microsoft's website for installing the redistributables... What exactly was wrong with just plain old mscvrt.dll?


Simple, mscvrt got replaced by that new library. What's wrong with the new one?

Draco Nihil wrote:227 is also bogged down with ridiculous "security features", ---


Unreal servers and clients alike were hacked multiple times by multiple people until stuff like Nephtys showed up. That shows one thing: security is a must in Unreal - as in any other multiplayer game - to keep trolls from having their way.

Draco Nihil wrote:In all honesty I would of wished that 227 focused purely on fixing bugs and compatibility issues rather than INTRODUCE compatibility issues. (from the result of people clinging to these new "features" saying it's paramount to their mod\mappack)


The 227 project has reinvigorated the mapping scene a great deal due to the new features as there are more options for our Unreal-based creativity. The UMS R&D mappers appreciate them very much as they are able to construct maps that look better, feel better and play better - and have much less BSP/HOM issues. Main factors here are static meshes that allow you to keep the BSP tree fairly free and the increased node limit which allows you to construct bigger and more detailed areas.

Draco Nihil wrote:I still and with great pride design my mods and maps with 224v. I don't care about the "new and exciting features" of the 227 unoffical patch. I never welcomed such features and given the amount of problems and inhospitality I was given towards my grievances with the patch's issues on my machine, I've refused to touch that patch even with a ten foot pole.


You are free to use what you want to, nobody can force 227 down your throat, nor is it anyone's goal to. But please take it into account that your tone that you voiced those grievances with at OldUnreal was much harsher than here and I'm not surprised these grievances were met with hostility. I know it from my own life. Whenever someone approaches me about something I - according to that person - screwed up, they better be polite, I'll hear them out fully. But if someone becomes hostile, I turn into a hedgehog under high voltage. Given how much time, resources and passion Smirftsch invested in his project, I am hardly surprised he doesn't allow anyone to go ballistic on him.[/spoiler]

pl1982 wrote:2. Is it safe to assume that the 'custom map reviews' and 'upcoming maps' sections of UnrealSP main site covers pretty much every Unreal 1 engine campaign/maps worth knowing about? I plan on becoming a more active member of the Unreal community here and it would be good to know that I pretty much only need to keep tabs on UnrealSP for all the Unreal single player goodness.


All maps worth knowing about? Not by a long shot, but we are continuously writing more reviews, so it will be. :D And yes, for Unreal single player goodness, just keep tabs on UnrealSP.
Last edited by Delacroix on 08 Apr 2014, 15:01, edited 1 time in total.
Image
I am the Unreal archivist and historian. If you have something from the past of Unreal that I don't have, do tell.

Smirftsch
OldUnreal Staff OldUnreal Staff
Posts: 135
Joined: 07 Oct 2008, 10:36
Contact:

Subject: Re: Please help a newbie: custom maps and engine question

Post Posted: 08 Apr 2014, 21:25

one should really think about statements by someone favoring Win98 over modern systems.

User avatar [UDHQ]Jackrabbit
Skaarj Warrior Skaarj Warrior
Posts: 89
Joined: 02 Aug 2012, 07:38

Subject: Re: Split: 227 technical discussion

Post Posted: 08 Apr 2014, 22:18

removed as per requested by admin


removed as per requested by admin

one should really think about statements by someone favoring Win98 over modern systems.


Yeah, I guess we should all use windows ME or windows Vista instead....
Last edited by [UDHQ]Jackrabbit on 08 Apr 2014, 23:53, edited 4 times in total.

User avatar ividyon
Administrator Administrator
Posts: 2354
Joined: 12 Nov 2007, 14:43
Location: Germany
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 08 Apr 2014, 23:04

I've never understood people's issues with Windows Vista; it's like everybody fails to acknowledge the existence of updates. Windows Vista Service Pack 1 and above is a perfectly nice and stable platform. Not as great as Win 7, but not THAT much worse, either. Therefore, yeah, Vista definitely is an incredible upgrade from Win98. :D

Also, since most of your response refers to a statement of Smirftsch's that he has since re-thought and retracted, I'd like you to edit your post out of fairness and remove it, too. :)

Also mind that I won't have you tell anybody to "go back to their forum", particularly when they are simply responding to someone else's out-of-thin-air rant about something they made. Keep it civil, folks.
UnrealSP.org webmaster & administrator

User avatar Delacroix
Skaarj Warlord Skaarj Warlord
Posts: 873
Joined: 21 Dec 2007, 17:22
Location: Poland.ut3

Subject: Re: Split: 227 technical discussion

Post Posted: 08 Apr 2014, 23:46

[UDHQ]Jackrabbit wrote:You don't have the manpower to make sure your patch is bug-free


It's a community patch, therefore community is that manpower. You want the patch properly tested? Have people install it, do a bug hunt, submit a series of reports. But given how little newcomers we have and how old blood slowly crumbles out... I guess we have to make do. It's a 16-year-old game after all. Even with the amazing community-attracting features of it, it was bound to grow old someday. We should be happy with the options we have. It's still better than the cesspit Epic left us in.
Last edited by Delacroix on 08 Apr 2014, 23:59, edited 2 times in total.
Image
I am the Unreal archivist and historian. If you have something from the past of Unreal that I don't have, do tell.

User avatar [UDHQ]Jackrabbit
Skaarj Warrior Skaarj Warrior
Posts: 89
Joined: 02 Aug 2012, 07:38

Subject: Re: Split: 227 technical discussion

Post Posted: 08 Apr 2014, 23:51

ividyon wrote:I've never understood people's issues with Windows Vista; it's like everybody fails to acknowledge the existence of updates. Windows Vista Service Pack 1 and above is a perfectly nice and stable platform. Not as great as Win 7, but not THAT much worse, either. Therefore, yeah, Vista definitely is an incredible upgrade from Win98. :D


Ironically, I'm currently using Windows Vista SP2 myself. Not by choice, but rather because its the only version of Widows I have a legit copy of since I lost my corporate XP cd. Windows Vista is a stable platform, but like 227 (yes I'm comparing 227 to windows Vista) it introduces a bunch of added security that is absolute garbage. Absolute garbage. Not to mention I've also had to reboot my system more than once because the Vista OS decided to enter an infinite loop via the "windows sidebar" which I disabled afterwards. There is no hiding that UnrealIntegrity.u was done all wrong and barely used by the online community. That fact alone makes Windows 98 a better choice in my book. I used it for years before XP and its a damn good OS. Windows 2000 is also a great OS which I used years after that.

ividyon wrote:Also, since most of your response refers to a statement of Smirftsch's that he has since re-thought and retracted, I'd like you to edit your post out of fairness and remove it, too. :)


Because I do respect you as the new "site manager" and respect the great updates you have given to this website and forum, I acknowledge your request and fairness and will remove it immediately as requested. If that resolve was only just as easy on a certain other Unreal website in the past.... hmm....

ividyon wrote:Also mind that I won't have you tell anybody to "go back to their forum", particularly when they are simply responding to someone else's out-of-thin-air rant about something they made. Keep it civil, folks.


Yeah, that was a bit out of line on my part. Were all Unreal players and equally in love with the game we play so any site or forum representing that game should be open and accessed to all unreal fans alike *cough* *cough*

It's still better than the cesspit Epic left us in.


Ha! Cesspit? Are you kidding? Dude, look at Unreal gold or even UT 436. Wonderful, great versions of the game that will always be recognized by players new and old. I don't know what cesspit you refer to that "epic" left us in, but I guarantee you that you are absolutely wrong about that. The biggest flaw with your point there is that 227 itself was compiled off of Unreal 226b (Unreal Gold)!

User avatar Delacroix
Skaarj Warlord Skaarj Warlord
Posts: 873
Joined: 21 Dec 2007, 17:22
Location: Poland.ut3

Subject: Re: Split: 227 technical discussion

Post Posted: 09 Apr 2014, 00:05

[UDHQ]Jackrabbit wrote:Ha! Cesspit? Are you kidding? Dude, look at Unreal gold or even UT 436. Wonderful, great versions of the game that will always be recognized by players new and old. I don't know what cesspit you refer to that "epic" left us in, but I guarantee you that you are absolutely wrong about that. The biggest flaw with your point there is that 227 itself was compiled off of Unreal 226b (Unreal Gold)!


Your guarantees mean nothing to me. From my personal experience: 226F network incompatible with 226B Gold. BOTH incompatible with the Anthology release. Installing 227 allows all these previously incompatible versions meet on even footing.

And the bugs... you somehow conveniently forgot the petitions for a 227 patch to Epic, or for a Platinum version of sorts. Bugs of 226 were recognized and people counted on them being fixed. That is happening.

UT 436? A good platform indeed, but we're talking Unreal and the Unreal patches, not UT.
Image
I am the Unreal archivist and historian. If you have something from the past of Unreal that I don't have, do tell.

Smirftsch
OldUnreal Staff OldUnreal Staff
Posts: 135
Joined: 07 Oct 2008, 10:36
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 09 Apr 2014, 00:22

I have to excuse myself for being that harsh. I didn't intend to insult anyone, I was just upset. Sorry.
To explain myself- I had to experience a lot of "attacks" in the past, even recently. Insults, disgusting photo montage at facebook, trolling in steam, racism mails, even threats. This all becomes plain to much at some point. I only see claims again and again, making me feel the only intention of some topics - like this one as well - is to discredit the patch, one thing seen often enough unfortunately. I'm open for critics, but not for claims and insults.

Now, to stay within the technical view- the bugs of 226 have been very well documented and archived in the Oldunreal forums and in the 227 release notes. They reach from annoying to invasive crashbugs and severe security issues. For everyone easy to read and follow. Its a hell a lot of stuff, over 150 bugs and that's only those I wrote down, there are countless more little things.

As for the security system, I don't know where you believe to have your information from, also its real functions have never been made public, but in any case it definitely works- if not I come to the point already mentioned- its a community patch, where are the problems with it, what would you would have done or like to see?

Same with the "crashes" and "performance issues" being claimed- where are details and facts about it? There were enough chances over the years, long before any of you has been banned. And if really willing any of you could have send a mail or re-register in the forums with a name I don't know, or even in other forums like here I often check for problems.

227i counts a few thousand downloads, only at Oldunreal, not counting the mirrors, but the number of bugreports is very low- unlike the mentioned number of problems reported in 226, which you maybe just got used to a bit to much over all the years.
As I did or at least tried for all years, give me something to work with and I try to make it better, but please stop telling something about massive problems on random forums without any facts.

User avatar [UDHQ]Jackrabbit
Skaarj Warrior Skaarj Warrior
Posts: 89
Joined: 02 Aug 2012, 07:38

Subject: Re: Split: 227 technical discussion

Post Posted: 09 Apr 2014, 02:40

Delacroix wrote:From my personal experience: 226F network incompatible with 226B Gold. BOTH incompatible with the Anthology release. Installing 227 allows all these previously incompatible versions meet on even footing.


Okay now I see were talking about two entirely different things altogether. The cesspool you were referring to are all the different versions of Unreal (224,225,226b,226f...etc.). I thought you were explicitly talking about a certain version of Unreal like "v.227" or "Unreal Gold (226b)" being described as a cesspool. Even if the version wars created this sort of "cesspool" and compatibility issues between versions, if websites like "OldUnreal" or "BeyondUnreal" advocated each user NOT to download the 226f patch for their Unreal Gold install then this cesspool situation could have easily been avoided. Of course there are gonna be patches for a game and different versions across the map available to the public. This happens for basically any game that actually amounts to jackshit. Think about it... Don't be so quick to blame epic for something we are just as responsible for as users. They didn't enforce what version were using for our Unreal install so why blame them?

I guess what I'm getting at is that you can't just call a patch "superior", just because its backwards compatible with all versions. In reality, this doesn't mean a whole lot for a game patch if everyone just used the version which was the most stable and had best results online as a server and as a client. Honestly, I'm wondering why 227 is still trying to remain backwards compatible as a client anyway. I understand the server side of it, but with all the new features it introduces it seems kind of pointless anyway..

@Smirftsch: I'm not questioning whether or not the functions in UnrealIntegrity work or not, I question more the design choice of implementing it as its own .u package in server packages by default instead of some server side .DLL which would make much more sense for security IMO. The goal shouldn't be to have a mod package where any one admin can blacklist whomever they like even down to things like the 227 subversion, but instead a server side DLL that would simply authenticate all packages from client to server to make sure they are in fact identical builds. I ask you, what more added security do you need besides that? Who is actually being helped by blacklisting things like consoles or disabling features like edit actor online? The more security that is added customizable by the admin, the more chances a legit client who means no harm will be unable to connect to a server because of a bad admin configuration. Luckily, I've noticed most Adkins just remove unreal integrity from their package list because they are simply afraid of just that. A bad configuration on their end which might not let clients in their server. Leaving these types of security configurations to the admin is undesirable in most cases and damn confusing in most cases. Wouldn't a standard preconfigured .DLL be a much more viable option?

Smirftsch
OldUnreal Staff OldUnreal Staff
Posts: 135
Joined: 07 Oct 2008, 10:36
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 09 Apr 2014, 14:39

[UDHQ]Jackrabbit wrote:@Smirftsch: I'm not questioning whether or not the functions in UnrealIntegrity work or not, I question more the design choice of implementing it as its own .u package in server packages by default instead of some server side .DLL which would make much more sense for security IMO. The goal shouldn't be to have a mod package where any one admin can blacklist whomever they like even down to things like the 227 subversion, but instead a server side DLL that would simply authenticate all packages from client to server to make sure they are in fact identical builds. I ask you, what more added security do you need besides that? Who is actually being helped by blacklisting things like consoles or disabling features like edit actor online? The more security that is added customizable by the admin, the more chances a legit client who means no harm will be unable to connect to a server because of a bad admin configuration. Luckily, I've noticed most Adkins just remove unreal integrity from their package list because they are simply afraid of just that. A bad configuration on their end which might not let clients in their server. Leaving these types of security configurations to the admin is undesirable in most cases and damn confusing in most cases. Wouldn't a standard preconfigured .DLL be a much more viable option?


Again, why do you think the .u is the base for the security?
Indeed I absolutely don't disagree with you here, that's the reason why the .u file is pretty much a helper only. Most things are done natively, also there were major changes in the last versions to heavily simplify the usage of it. Not sure if you noticed that. And before you ask- there is no separate dll and it was integrated into existing dlls in order to avoid hacking of this possible single .dll file.

Of course there is always a chance that a bad config can cause legit clients to be kicked, the problem is old and known very well. It was never easy to configure anticheat systems properly and if really necessary it is and always will be some work for the admin, requiring surely quite some testing to avoid that. Also I agree that some admin is simply overcharged with that, but I and the admins I know surely will give a hand with it if needed.
The new configurations are quite simple compared to the old version and no matter with old or new version of it, it is working out of the box for the most part. The newer version also features SHA instead of md5, which is surprisingly also faster to compute, so chances that older system timeout are reduced as well.

But to be honest I am more than happy that in most cases the integrity service is not needed anymore, the remaining community seems to be grown out of the need for it luckily - in most cases at least. Yet I wouldn't participate f.e. in a DeathMatch competition without it :)

User avatar Draco Nihil
Skaarj Lord Skaarj Lord
Posts: 197
Joined: 06 Jun 2012, 21:18
Location: Independence, Kansas
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 10 Apr 2014, 07:28

I have no reasons to attack Smirftsch, I'm merely criticizing the integrity of the 227 patch given how it basically is a "grabbag of features". I would of appreciated if 227 was totally grassroots and focused only on fixing bugs and increasing stability of the engine itself. Unreal has alot of left over crashes that should honestly be gracefully handled: like the BSP Occlusion overflow and the Actor Channel Non Open Packet errors. Another good thing to fix would be the node builder for the maps themselves, instead we got "static meshes" and of course 227 only maps. Above all though, providing "modern" renderer's that provide a better baseline for newer GPU's and drivers is paramount, not providing the usage of shaders, S3TC, etc... Unreal really, and I mean really needed OpenGL 4.x and D3D10 renderer's just to get around the horribly written drivers of today's generation as vendors drop or screw up backwards compatibility in favour of improving and maintaining the performance of the "bleeding edge" versions of our most common render API's.

Galaxy also is easily exploitable to cause peoples machines to hard lock when playing certain sounds or module files. But really I was the only person exploiting that back in the day anyways... Nobody really truly understand what made it freak out, I never did either. All I knew is, some modules and sound files will cause Galaxy to freeze Unreal and in turn freeze up your entire system forcing a soft or hard reboot.

I forgot which build of 227 was that didn't give me the stuttering problem but the amount of issues I seen coming from my lover's own accounts coupled with the almost same exact effects I got, is what really geared me to strongly dislike the patch. It's nothing to do with Smirftsch's personal life and never has had to do with it for me anyways. I just disagree with the philosophy hanging around the patch when it comes to "features over bug fixes".

I've personally seen what happens when compiling stuff with newer compilers for something as old as 1998, it causes alot of really obscure problems I can only guess is related to how the newer compiler tries to generate optimal assembly code.

I really apologize if I started a flame war over this but, I stand by my reasons for not wanting to use nor endorse the 227 patch. I don't accept where it went, I just plainly don't and it's my opinion and not anyone else's so there's not much I can do but grieve to myself.
“I am the dragon without a name...”

Smirftsch
OldUnreal Staff OldUnreal Staff
Posts: 135
Joined: 07 Oct 2008, 10:36
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 10 Apr 2014, 08:51

Draco Nihil wrote:I have no reasons to attack Smirftsch, I'm merely criticizing the integrity of the 227 patch given how it basically is a "grabbag of features". I would of appreciated if 227 was totally grassroots and focused only on fixing bugs and increasing stability of the engine itself. Unreal has alot of left over crashes that should honestly be gracefully handled: like the BSP Occlusion overflow and the Actor Channel Non Open Packet errors. Another good thing to fix would be the node builder for the maps themselves, instead we got "static meshes" and of course 227 only maps. Above all though, providing "modern" renderer's that provide a better baseline for newer GPU's and drivers is paramount, not providing the usage of shaders, S3TC, etc... Unreal really, and I mean really needed OpenGL 4.x and D3D10 renderer's just to get around the horribly written drivers of today's generation as vendors drop or screw up backwards compatibility in favour of improving and maintaining the performance of the "bleeding edge" versions of our most common render API's.


There are A LOT of things to say. First, the features. You say that 227 would feature features above fixes- which is plain not the case. Any bug which has come to my knowledge was addressed. Of course there are always things left, some very difficult to fix, some impossible, some only to fix with new features. Example: in order to fix the most heavy source of crashes in older versions especially for servers, the FCollisionHash crash, the octree system was built in. The existing system was in itself flawed and could not be fixed. This again required a couple of other changes, mostly to the mover system which relies on it and had ironically some trouble then with the increased precision of the octree. And there are many of these examples. Many features are fixes or fixes depend on them!
What do you have against features anyway? The increase of size is negligible, even on 10 years old machines and the speed doesn't suffer from it. Also almost anything is absolutely optional. I don't get it, really.

Then there are a very very few crashes which could still could not be tracked down in all years because any debugging effort lead into dead ends and the source could not be identified. Overflows, like BSP occlusion- but even there I found lately a possible reason and it should be better now. Either way this crash is very rare on normal maps and mods, I haven't seen it in years if not triggering it by purpose.

There has been quite some work on the node system as well, but this system has its limit also and don't forget that changes can open a can of worms with problems of other systems depending on it...

So yes, yes, there are limits, limits what I can do, limits whats possible. Games like Unreal are usually done by a few people, if not a whole team, each one expert in one specific section, like graphics, sounds, engine, mapping etc etc etc. and not by a single person with a very few enthusiastic helpers who have been limited badly by not having access to the most vital parts.

The static mesh system was logical step and there are little disadvantages to enhance maps with it. There are only a very people helping me in this project and their possibilities to help with it is very limited due to the closed source. The static mesh system for example was made by dots with informations about the mesh system from the DeusEx headers, people contributing are very rare and why shouldn't such a great addition built in?
This leads to your critics about OpenGL and newer renderers- its a perfect example for things which could be done by other people, ANYONE could do it. Anything to do it is known and out there. But there are no such projects. Not by you, not by anyone else- indeed I am working on an OpenGL 3/4 renderer, but it eats up a lot of time and I have only limited time, so I don't know if I can or will ever finish it. I am not being paid for all this in case someone assumes that. I get the same for my work anyone else does: nothing (plus paying for the page as well, but this happily works out usually with the donations).
I have absolutely no clue about D3D10 and yet I fixed the most obvious bugs in a later build, but its way slower in performance compared to the "old" renderers and still suffers some very noticeable bugs yet. Things I am unable to address until I find the time work myself into it and then it's still not easy. Time I don't have currently and which I am not willing to sacrifice, time I rather spend with my family, not talking about my health. After all it's my hobby and nothing I earn money with. Period.

Galaxy also is easily exploitable to cause peoples machines to hard lock when playing certain sounds or module files. But really I was the only person exploiting that back in the day anyways... Nobody really truly understand what made it freak out, I never did either. All I knew is, some modules and sound files will cause Galaxy to freeze Unreal and in turn freeze up your entire system forcing a soft or hard reboot.


Many galaxy bugs are originated in the old galaxy soundsystem, the library it is based on. Casey managed on some point to get the sources for it, but its not the same version which was used for Unreal and although we managed to fix the crashes it still doesn't work correctly. Its a newer version which was probably given up in between the update. Its a project for itself even before you can start updating the the Unreal implementation at all.
Therefor we have a lot of alternatives. FMod surely became deprecated over the years since its based on FMod3, but we have OpenAL, which I updated in the last version to use libxmp instead and Swfmod (a polished up and fixed up version of an abandoned sound project for DeusEx) which is based on FModEX.

I forgot which build of 227 was that didn't give me the stuttering problem but the amount of issues I seen coming from my lover's own accounts coupled with the almost same exact effects I got, is what really geared me to strongly dislike the patch. It's nothing to do with Smirftsch's personal life and never has had to do with it for me anyways. I just disagree with the philosophy hanging around the patch when it comes to "features over bug fixes".

Again see above my comment to "features over bug fixes" - many things depend on each other and often one leads to another, but I repeat it another time- I tried to address ANY bug which was reported over the years.

I've personally seen what happens when compiling stuff with newer compilers for something as old as 1998, it causes alot of really obscure problems I can only guess is related to how the newer compiler tries to generate optimal assembly code.


VS2008 is hardly one of the "newer" compilers. It is a very reasonable and thought through choice to have a better compiler, which produces indeed a lot faster and also more stable code, its really no bleeding edge stuff but major and stable. The complete codebase had to be reworked and updated already for VS2005 anyway because VC6 produced way to many issues and also has a lot of very well known bugs.
Lastly, let Win98 finally die, its no argument, the lack of support for it in VC2008 is of no interest anymore. If you have such an old machine, stay with 226 and the voodoo cards. It was a lot fun back then and it still runs impressing fast with that combination (if you still have such a system running that is), but these times are over.

I tried personally 227 on old systems from 2001 to modern machines, with 2K in the beginning as well, with XP and Vista, with Win7 and Win8, with 32bit and 64 bit. On any of these machines I could see an performance improvement, on some old laptop it even was up to 200%. This doesn't mean and I don't want to say that your stuttering is or was not existent but the cause for it is impossible to say this way and a few problems like these have been resolved after being reported in the forums.

I really apologize if I started a flame war over this but, I stand by my reasons for not wanting to use nor endorse the 227 patch. I don't accept where it went, I just plainly don't and it's my opinion and not anyone else's so there's not much I can do but grieve to myself.

I have nothing against critics and also nothing against opinions, but I could explode reading again and again claims with no valid or explained background and facts, claims and opinions presented as they were facts, creating false and non objective impressions for others.

---

I hope this helps a bit to understand that all this is a very complex subject and not everything is "straight forward" when addressing issues. Decisions have to be made, compromises have to be done and it rarely works out in a way everyone is satisfied with it. Of course some decisions also turned out to be wrong and have been revoked but it definitely works out fine for the most part, even although not everyone can agree with every decision for sure.

User avatar [UDHQ]Jackrabbit
Skaarj Warrior Skaarj Warrior
Posts: 89
Joined: 02 Aug 2012, 07:38

Subject: Re: Split: 227 technical discussion

Post Posted: 10 Apr 2014, 13:53

I just want to state that on my Unreal gold install I'm using D3D9 with FMOD support and take my word when I say when I open my unreal gold client to play Unreal I wouldn't be able to tell you that ituses 227 or not. What I found is that my unreal gold client feels very refreshing as it contains the unmodified original UnrealShare and Unreali packages, no added client security like disabling edit actor in certain cases (which I DO use in online LAN games alot to debug my mod) and I haven't experienced any crashes that were not infinite loops from my own state code, or game breaking bugs. I think the octree enhancement might go a long way for some users who play unreal, but a careful mapmaker and or modder can most likely dodge all issues in this so-called "flawed existing system that was built in". The reality is that everything is flawed in some ways more than others, but the harder you try and find those flaws the more fixing them seems like a major improvement.

Smirftsch
OldUnreal Staff OldUnreal Staff
Posts: 135
Joined: 07 Oct 2008, 10:36
Contact:

Subject: Re: Split: 227 technical discussion

Post Posted: 10 Apr 2014, 14:27

what can I say? all that I feel when I open Unreal 226b is that it is slow, takes endlessly to start if not using at least D3D9 or newer OpenGL and also feels jerky. How it can feel refreshing if you have a few more or less kb in you UnrealShare and UnrealI is a mystery to me, but granted, if that's your impression, why not, I'm perfectly fine with that. Back then before 227 I also prefered 224 over 225 or 226 when playing because it felt better to me.
Also I never denied the benefits of EditActor, but it opens to many vulnerabilites which are not only of theoretical nature but really have been abused, and I bet it counts to the most disliked decisions ever, but this is one of the decisions which are really justified, despite the disadvantages of losing EditActor.

The example of the Octree/FCollisionHash however is only one out of many and I fully believe you if you say that you don't have any crashes or troubles running it (well, I simply assume now you use 225 as server, since 226 has a lot of extremely annoying replication issues as server) - however, that's something many server admins and players experienced otherwise, as it still can be read in the archives (or simply google for FCollisionHash). I don't need to mention that this also heavily depends on setup, purpose and usage of the server.
Surely there is no flawless system as you said, but even with dozens of additional checks and catches it was impossible to manage the problems with FCollisionHash (to get it fixed would have required to rewrite the major part of it from scratch anyway) and using the Octree not only fixed all these things at once, it's also faster, more precise and I was able get rid of all the additional checks and catches, which should make it an easy understandable step.

Next

Who is online

Users browsing this forum: No registered users and 20 guests

Copyright © 2001-2024 UnrealSP.org

Powered by phpBB® Forum Software © phpBB Limited