No joke :)

[TCP_Wolf]

There is horrible bug at UGold and maybe at RtNP 226 too. When you click on start multiplayer game or botmatch, it will take several minutes to load, especially if you have many mods installed, but at Ut it is question of few seconds. It isn't dependand how many mods you have installed too.

The problem exists in UT just as well, however, the amount of mods is less severe than the amount of MAPS.

[CrowindPHX]

Ok, I dunno if anyone has already posted this and the search doesn't bring it up, so I assume not.

This bug is a rendering issue in the Unreal Editor. Now I don't know if you have any way to fix bugs in the Unreal Editor's renderer but here's the error I get when working on some maps.

Code: Select all

History: URender::ClipBspSurf

[Leo T_C_K]

There is horrible bug at UGold and maybe at RtNP 226 too. When you click on start multiplayer game or botmatch, it will take several minutes to load, especially if you have many mods installed, but at Ut it is question of few seconds. It isn't dependand how many mods you have installed too.

The problem exists in UT just as well, however, the amount of mods is less severe than the amount of MAPS.

No, at UT I have even more maps than at UnrealGold and if you mean it is due to coopmaps, it isn't, because it is when I click on botmatch or new multiplayer game first time. When I click on coop it will load more time, sure. But at UT it won't freeze me first time, there is something wrong, it takes really several minutes to unfreeze. Anyone got same problem? I really haven't that at Ut when I click on practice session, or multiplayer game. It loads at two secons mostly. I use UT:GOTY 436.

[TCP_Wolf]

I use normal UT 436 (non-GOTY), and when I click on BotMatch/DM I have to wait at least one full minute before the 3000+ maps I have installed are listed. In the meantime, I can go to the kitchen and get me a nice cup of coffee.

[Leo T_C_K]

Ucc needs more functions, like at UT.

3000+ maps? No wonder then. But there is really something wrong with ugold loading.

[Smirftsch]

anything specific for ucc ?

[Leo T_C_K]

If you type ucc help at commandline at UT, it will give alot more commands, like batchexport, etc.

[Smirftsch]

i'm aware of that...just wanted to know if you miss something SPECIFIC

[HbG]

I can think of a million features for a possible 227 patch (perhaps bump the version to 230), but bugfixes. Not any that have already been mentioned i think.

Although.. If you use one of them purple blocking volume items, and you jump on top of it, hold crouch, you will stay suspended in the air, but other players will see you fall down. Has this been mentioned yet? Amazingly this bug is still present even in the latest UT2004, i sometimes get it when hitching a ride on vehicles in onslaught.

Another thing i miss, is the ability to run editor commands from UCC, like you can run console commands during compilation via #EXEC lines, it'd be nice if i could do this without compiling anything and without first loading the whole of unrealed. I like using scripts to build packages, it's clean, and such a feature would be immensely powerful.

In a similar light, once this is available frontend commandlets can be written (perhaps even scripted) for batch import/export, importing fonts from windows, or hell, even creating entire maps by loading Unreal map text files.

Which brings me to another thing. When loading a map in text format, such as when converting maps from UT to Unreal, you have to preload every single texture and sound package referenced by the map, or it will load with it's textures or sounds reset to default. This is cumbersome and time consuming, it would be nice if the editor could build a database of all textures/sounds available and load the packages as required. But that'd be a 227 thing really, and not a very important one.

And i just thought of another thing: a commandlet that can merge conflicting files and create one that's compatible with both.

My Personal 227 Wishlist would be:

• Compressed HTTP redirection for downloading files. Preferably using the LZMA algorithm.
• Allow to specify a separate maximum speed for file downloads from the server, optionally employ on the fly compression.
• Optionally use ipTOS to classify network traffic as "Minimize Delay" and filetransfers as "Maximise throughput" or possibly "minimise cost".
• Ditch the old console and use UBrowser for everything, make sure the cursor can move without deleting text, etc etc.
• The ability to paste text into the console from the clipboard.
• Support for additional mouse buttons (side buttons 4 and 5, many mice go even further), again modern games support this already.
• Compress the network traffic if this doesnt happen already, Deflate, PPMD, huffman, LZMA, it'd be worthwhile to evaluate the different algorithms, ppmd especially would be promising as it's symmetric.
• Option to limit network packet size to trade latency for bandwidth on slow links, and MTU path discovery.
• Allow framerate to run at multiples of the client's upload tickrate, to enable high framerates for low bandwidth links, and prevent excessive upload bandwidth for players with high framerates and netspeeds. UT200x does this also.
• Convert non-animated meshes to static meshes and upload them to video memory for improved performance. Would probably work for movers too, but i fear BSP doesn't take messing with.
• Backport the UT netcode.
• Support for replicating large variables such as big strings and arrays reliably.
• Measure a player's ping time more accurately.
• Make a player's IP address easily accessible from script.
• Perhaps send another unique identifier to counter ban evasion. Possible candidates would be hashes of: The processor serial number, the windows serial number, the computer's machine name (already available), a cookie in the registry. None of these are really secure though.
• A system to hash packages with a secure algorithm such as SHA-256, to ensure client side authenticity.
• Support for adding serverpackages on the fly like it exists in UT200x, this is much more flexible.
• More hooks for mutators, basically bring it to the level of UT200x.
• Don't transfer deathmessages as text, this also means localisation of deathmessages is done on the client rather than the server.
• Linux and possibly 64 bit versions. If a full client is too much work, then at least port the server over. It took Ryan C Gordon only a day to prepare ut2003 for 64 bit linux, Unreal should be a peice of cake. Must use SSE however.
• That holy grail of unrealscript: Dynamic arrays. Not very critical imho.
• OGG music support, it would also be worthwile to store samples as ogg vorbis in .uax files and decompress them on the fly, it would save a lot of space.
• Write a Cache.ini file, or just dont store files as guid's in the first place, it shouldnt be hard to figure out outher ways to work around conflicting filenames.

That's all for now.

[Smirftsch]

LOL, wasnt here for centuries and now i have a list of 1000 points

Welcome back old friend

First 227 will be for the mainpart only bugfixrelease, most new features will probably have to wait for 228. The netcode of Unreal and UT are not compatible, and it isnt worth the work to backport it. The idea is maybe to use the UT engine for 228 and build in the fixes we made already, but this will mean a break in backward compatibility, otherwise it won't be possible then- currently a problem because a lot of people won't accept that, it seems- if 227 is a succes people will hopefully change their mind. The same problem would be for a lot of ther requests you have here...

Yes, the bug with the forcefield, sure, well known, but minor because happens very rarely.Will put it on the todo list.

For linux and 64bit ports- for UT there is a linux port existing, for Unreal isnt- so it wouldn't be still a lot of work- possible however. Almost the same for 64bit ports- i already had a look, it shouldnt be that hard, probably even easier to make it, but i lack a 64bit development environment for that....and again the question of "is it worth it"

Unreal runs pretty fine in Linux with wine, the same for 64bit Windows.

For a lot of other things- how about taking part in the project ? Of course i can't give ya the source access, but for a lot of scripting things and advices you can probably make, it would be great.

[Hyper]

About the last request of HBG:

If you would ever disable the saving of downloaded files as GUID's (cache files), be sure to make it optional.

At least I do not want to manually install / delete / rename all those different uteamfix / edm# / aura# / hb# files every time I connect to a server.

[HbG]

Hyper.nl, i didn't mean disable storing the files, i just meant storing them with their original filenames instead of guid's, or just write a Cache.ini file like UT has. Transient downloads that don't get written to disk may be useful for security related packages, but it'd leak out sooner or later anyway.

Smiftsch: With regard to the UT netcode, i was aware of that. Net compatbility has been broken before, and while all the other points i mentioned don't have to break anything with careful programming, it would be a problem. The question is indeed, is it worth it... I'm not up to date on the exact details.

Thinking some more about it, because it's all scripted instead of the native replication of UT200x, it might be possible to implement it in all-new functions in the playerpawn, so the server can use different functions of the netcode depending on which is present in the client.

Regarding 64bit, the main motivator here is the additional performance enabled by the presence of additional CPU registers, and the forced use of new instruction set extensions like SSE over the older old extensions. The ballpark figure appears to be a 15% speedup, i think that's quite significant, and porting is supposed to be easy (but i'm still not a C programmer . And there is that cool factor.
As for linux, yeah wine works fine. In my absence i've become acqainted with FreeBSD, and i'm playing around with Gentoo linux on some spare hardware. Unreal runs fine under wine, it works as well as any native app. That's only the server though, but i agree with what you say, it's not the highest priority.

Just thought of another thing or two to that *may* be worth considering:

• SSL support for TCPLink (for secure remote administration). Hell, make it SSH for all i care.
• Function to catch log output in unrealscript, again to aid remote administration and general monitoring.
• StdIn support for UCC. (present in UT200x).
• Native functions to chop ints to bytes, or hex strings, and back again, and read individual bits, etc. Basically all the important bit- level operations. This is to catalyse efficient use of the sendbinary and read/receivebinary functions in TCP/UDPLink, as it's pretty damn hard to use them effectively as it stands now.
• Backporting the BufferedTCPLink class might be useful too.
• Use a special switch to allow compilation of unrealscript that changes const variables. To save you the hassle of bytehacking it all.
• Or enforce const variables during runtime instead, so they can't be changed by scripts at all.
• Tab completion for console commands like Half-life has. Tab completion for classes and variables would be really cool too.
• Advanced string operations like UT200x offers.
• A library full of useful static functions performing all sorts of tasks so developers don't have to invent the wheel everytime. But such a thing would be a separate project really.
• Ubrowser extensions such as:
• An irc client.
• Perhaps a remote administration panel to function as a poor man's webadmin, or just a telnet client, whatever.
• And project related we have:
• A separate project website.
• With a bugtracker.
• And a betatesting program.
• Some sort of source management application that can be used with unrealscript.
• A name for the project.
• A PR hype when it's ready for release. I want to see it slashdotted or something, blow some life back into the game.

Damn, and i wanted to keep this post short...

[Smirftsch]

to be honest, a few of these things, especially the parts you mentioned from new uengine games say nothing to me- i simply don't play them, and i'm already happy that i find that much time for unreal i do already- which leads me to the next question- of course a page for this project would be nice, but who's gonna make it ? who's maintaining it ?

Regardless that it took years for oldunreal to become public enough so that i can say a big part of the community is aware of we are doing here... -

64bit port- i know, you are absolutely right, but i don't have the software for that. (Although, to be honest, a linux port would be more interesting for me)

for betatesting- the first tests will be inofficial anyway, and in the moment it can be called stable enough it will be mailed to every bigger unreal page- but which of them is announcing it...i really don't know...when 227 is ready i'm gonna ask @ Epic's to announce it at Unreal mainpage, but can't tell if they will really do it.

bugtracker and sourcemanagement for scripting ? nice idea, since i'm really not good in scripting it's often difficult for me to see if there are problems, especially because there are people in here who know way more than i do in uscript

i think i could get a subdomain for oldunreal, maybe like development.oldunreal.com or whatever, that wouldn't be a problem, but i can't manage/maintain it, i simply don't have the time for it. (Hell there is so much which could be done that i probably could do it as fulltimejob if someone would pay me for that... )

[HbG]

Yes, the way i suggested it it is simply too much work to be done by any one, or even a small group of people, there will have to be a simple "mission statement" site (in a subdomain) and a recruitment process. Apart from the programmers and scripters there will have to be webmasters and administrators at the very least.

A bugtracker isn't too difficult, GNU's BugZilla software will suffice, i don't have experience administering it, but i don't expect a big challenge there (ive got some experience with installing and administering mantis, but i don't like it). The only source management systems i know of are CVS and Subversion, and i don't have any experience with either of them beyond some automated scripts in FreeBSD, but i'll ask around and see if anyone can get me up to date on it, and how well it would work for unrealscript. There's always tried and true FTP, anyway, and it would be fine for starting out with.

Another thing just occured to me, under what license have Epic made the source available to you, what are you allowed to do, and what not?

I was thinking, with the arrival of Steam as a distribution platform, there exists the most wonderful opportunity for re-releasing Unreal online for a small price, if Epic would allow this. There is always an interest for retrogaming and the possibility of some financial compensation for the work done sounds promising to me. It sure beats begging through paypal, and it would reintroduce Unreal to a large audience, breathing more life in the community. As much as i have a true Unrealer's dislike of Valve and Half-Life 1/2/CS/whatever, from a business perspective Steam is the future. Mark my words.

As for introducing some features from UT200X, they are mainly the ones that have made scripting certain certain operations so much easier, or allow you to make changes without subclassing the gametype and the entire tree of playerpawns (i'd love to get rid of that whole thing to begin with, but that'd be a major break).
For a project such as this, it'll be necissary to discuss the proposed additions in detail and sort them based on script or native code, backport from UT99/2003/2004, or new feature. I'm considering everything conceptual for the time being.

And last of all, you not having a 64 bit system? I'm surprised, if anyone in my memory had access to the latest & greatest it used to be you.

[Smirftsch]

well, times are changing, and due a betrayel 2 years ago i lost that much money that i still couldnt recover from it. The hardware i have, but for a winxp64 and new visual studio which supports 64 bit programming there is simply no money.

For the license- i'm allowed to work with it, to make fixes and updates with it, and to offer the updates & fixes freely to the community. Thats it.

Well, let me know what you can do, and we are going to make it

[Bane]

Now, correct me if I'm wrong, but wouldn't adding md5/sha256/whatever package/file checking to Unreal227 require the client to use 227, as well? Which would also mean that anyone who wanted to avoid the hash check could simply use 225f, because 227 will also be backwards compatible?

[Smirftsch]

Now, correct me if I'm wrong, but wouldn't adding md5/sha256/whatever package/file checking to Unreal227 require the client to use 227, as well? Which would also mean that anyone who wanted to avoid the hash check could simply use 225f, because 227 will also be backwards compatible?

currently it seems that we have to find a good protection which is backwards compatible, because for some strange reason i had to recognize that not everyone wishes to update, so the only way is to make one backwards compatible version now - thus the maintarget at the moment is only bugfixing for 227, and once people are satisfied with this "not Epic original" to start workin on 228 which will be a compatibility break almost for sure.
Don't see an other way.

[HbG]

I don't think it's worth all the additional effort to create a version that is both backwards compatible and secure, when it can be done much simpler. It could be implemented and the choice left to the server admin whether or not to allow pre-227 clients.

Personally though i think it's a load of bollocks and if you don't want to upgrade, too bad.

I'd like to hear their arguments for not upgrading.

[Bane]

Smirftsch: OK, just making sure you guys weren't just planning on making this superb hack protect that could be easily disabled by using 225. It is still a good idea to add it, as you said, for 228. I'm assuming that 228 would only be compatible with 227 and 228, which would allow a 227 client to join any server

HbG: As for not upgrading, I'd say that the biggest reason for someone not to upgrade is sheer ignorence. Unreal somehow seems to have a good number of newbie players, and of course a good number of very stupid players. The first likely don't know about this patch, and might not know where to get it, or whatnot. The latter probably wouldn't know how to apply it... "Where's this oldunreal.com?" This is probably oversimplified/exaggerated, but there are definitely going to be people who don't use 227 because they don't know it exists.
Also, like I said, chances are almost any hack protection would require the client to be on 227. I could easily just bypass that and use my bot by using 225. For a 227-only switch, that might be fakable.

[HbG]

Bane, that's why i said it could be left up to the individual server admins to decide whether they should allow older clients or not. 228 only could be cheat free (assuming 227 is a bugfix only release), and with allowing older clients to join, you consciously take the fact that with them you might draw in cheaters as well. Also just checking hashes doesn't make it cheat free, it takes a lot more than that.

I also found another bug in the 225 server. I was playing private coop with some friends this evening and when i shot an altfire blob with the biorifle on a baby cow, it crashed with an infinite recursion of spawning cow carcasses. I've never seen it before, but i can't imagine people not shooting babycows in every possible way, either.

[Zombie]

I also found another bug in the 225 server. I was playing private coop with some friends this evening and when i shot an altfire blob with the biorifle on a baby cow, it crashed with an infinite recursion of spawning cow carcasses. I've never seen it before, but i can't imagine people not shooting babycows in every possible way, either.

This has been documented for a while, and there is a way to prevent it within a mutator. A real fix in the core packages or native code will need to be done though.

That patch wishlist certainly looks very nice, HbG. The only parts I don't like as expected by others is the mention of breaking compatibility. I wouldn't mind if the break was only one way. What I mean by that is breaking 224-226 client compatibility with 227+ servers (with admin option of course!) can be exceptable. Although breaking client compatibility for 227+ clients to join older 224-226 servers I hope can be avoided (built-in legacy support) if possible. I don't think we can ever count on a majority what's left of the unreal1 community to follow along with every patch. It's just too fragile as it is with only about 80 servers and a lucky chance to even get that much players in the evenings.

    Also, I'm beginning to worry about how these possible feature additions will effect mod compatibility. The thought of having to work more to maintain cross version mod compatibility as a developer is of concern. Whenever the existing core U packages have new variables or functions implemented that brings in new incompatibilities with older patches if a developer ever uses them. Same can go with changing existing function parameters or what they return in 227+ patches when a mod is compiled in 225. If it's absolutely neccessary to sever complete netcode compatibility with older patches at some point then IMO that should be when the new variables and native functions are added/changed.

Maybe these issues and concerns can be thrown away if we can gather enough publicity, and get gamers to go retro so we have a bigger community again.


-Zombie

[Bane]

HbG, one of the points I was trying to make is that a version check could be faked. I'm assuming the only way to drop 224-226 players from a "Only 227 Allowed" server would be some kind of version check. How would this be done? I've been UProtect do it. However, I'm fairly certain that is based on the linkers, and nothing more concrete. What if it is faked, and the Server thinks the client is 227? I'm guessing it would also be possible to produce faked security responses, and probably easier than just trying to hack 227 itself. (Writing stuff like this would probably be easier if I knew more about the current plans for 227...)

Ugh. anyways... the point I'm trying to make is that servers being able to exclude 226- clients would probably be more hassle than its worth. All of the problems with full broken compatibility, and I do believe fewer of the security benefits of full incompatibility.

[HbG]

I am liking this discussion.

Yes, compatibility with the existing codebase must be maintained, but most of the changes i suggested either result in new (native or scripted) functions, or get done in the native code entirely and thus operate transparently (such as net compression).

Bane: A fundamental rule in computer security is that nothing is secure if the hacker has physical access to the machine. This is always the case with online gaming as the cheater has control over every bit in every binary and every bit of input and output on their computer. The only trump we have is control over the source code.

If there will be security related features in 228 they should of course be implemented in such a way that anyone who succeeds in succesfully pretending to be a 228 client with all the checks and changes that come with it, without being one, and without access to the sourcecode, is a genius. It is definitely possible to get it secure enough that noone within the relatively small community will be able to make the effort to crack it.

[HbG]

I just had another idea or two:

• Store passwords on a per-server basis and use a friendly UBrowser dialog. Remove the password entry in player setup alltogether. It doesn't belong there.
• Modify the hud and fonts to maintain relative size and readability at resolutions up to 2048x1536. That should make it future proof enough.

I had also been using UT2004's ucc dataripcommandlet to rip Unreal's texture packages in an attempt to make a small dedicated server package. I was able to get the server to start using about ~10MB of texture packages, i could rip all of them except UBrowser, but the server appeared to crash when loading any package referencing the native stuff in Fire.dll, so i had to copy a few original packages back, or i would've gotten it down to 1.7MB. Some packages also got larger after ripping.......

However, when joining the server i would get loads of hitches (but no mismatch errors or anything), the server log complained about not being able to load textures and threw me accessed nones. It seems with the current state of the engine it can only work for textures not referenced from script, but only used by levels. It'd be nice if this could be fixed and Epic's dedicated server license applied to Unreal. With sounds and music ripped too it would be possible to create a free, dedicated server install measuring only (rough but educated guess) ~80MB. Again, things have changed since 1998 and i know server admins will want this. After all, retrogaming isn't just playing old games. It is playing old games with today's standards in usability.

[Smirftsch]

the umenu from UT or UGold i have already implemented, for the password dialog, yes, not done yet, but for a long time already on the todo list.

For such high resolutions...no idea, can test up to 1280x1024, which works fine....

nice idea for the server however