No joke :)

[TCP_Wolf]

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.

This problem is caused by client prediction, because the client knows that a non-sustained pawn in mid-air has "Phys_Falling" and thus... falls to the ground. Why the server decides to keep the pawn up in midair, though, is a mystery to me. However, since the location of the pawn does not alter on the server, the server will not send a continued "update location" to the client telling the client the pawn is still in the air where it was just the moment before... because Unreal is so "smart" to only send data that actually changed.

[*]Make a player's IP address easily accessible from script.

Already exists... Nephthys API...

[*]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.

... and why the heck are you posting this here? We have a developer board with people who specialized in such topics where you are on as well!! But no you post that here... bah

[*]More hooks for mutators, basically bring it to the level of UT200x.

EDM and UTF have added "events". The idea of adding new engine calls is not new though.

[*]Don't transfer deathmessages as text, this also means localisation of deathmessages is done on the client rather than the server.

I hate localization, but that's just my opinion. In Crystal Chaos for ut2k4 it has always been more hassle than worth, and what you could do with one line of code in Unreal One suddenly required several entire CLASSES(!!!) in ut2k4? Only for localization? PFFFT!!!

For example: we have a bonus message with a variable bonus value such as....

"You just earned ..somevalue.. extra points."

If sent as text, all you do is Blah.ClientMessage(...)

With message classes, you need to send the class along with the bonus value and have the client decode both to set it back together. While the technique is clear, the effort it made to get right was outrageous compared to the result!

Yes I know it is way more network efficient though....

[*]That holy grail of unrealscript: Dynamic arrays. Not very critical imho.

Just a dumb question, who will use features like these?? Mod writers? Certainly NOT! Because they will want their mods to remain backwards compatible...

[TCP_Wolf]

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.

http://newbiesplayground.com/dogforum/viewtopic.php?t=940




HBG,
I like many of your ideas, but I had wished you had brought yourself slightly more up to date on existing mods.

A few things from your wishlist were also started (venimous already had a grab on a http server a time ago), but overall you come with a large list of stuff all at once. Also, a few things may not belong on a publicly available forum...

Another example would be "reliable large array and string replication"... you know what's weird? 224 actually had that at least to a greater extent than 225!! And also, scripted solutions for this exist (I wrote 2 myself!).

And I very much agree with Zombie on the compatibility problems with existing mods that a few changes may yield. Just take the console thread and the "state code problem" (use the search function to find the thread lol).

Changing the "playerpawn" move functions - when needed with enhanced netcode - is probably another good idea... just too bad that for things like my "224 compatible old menues with mouse support in fullscreen mode" I was required to override some of the events there to capture mouse movement... so again I would fear other mods (not just this one from me) would have to be rewritten to accomodate such changes. Same thing as the state code console....


rant rant rant... from somebody who really wrote a few things lately for Unreal... Your persecptive is mostly ut2kXX, so please bear with us Unreal One oldies. I'm afraid

After all, retrogaming isn't just playing old games. It is playing old games with today's standards in usability.

this will not hold true once it comes to IMPLEMENTING it...

[TCP_Wolf]

.... and I'm really sorry, I didn't want to sound unhappy or put anything you said down, I am just a pragmatist

[Hyper]

Don't we have dynamic arrays already? ini entries like Paths=, ServerPackages=, ServerActors= (Without index number) seem to indicate that there is some kind of dynamic array.

[Hyper]

oh, and by the way: These arrays should be enlarged in the new Unreal version:

The UBrowser tab gametype lists like

[UBrowserPopulated]
[UBrowserDeathmatch]
[UBrowserTeamGames]
(etc)

They now have 8 or 10 entries, I would recommend to set this to 32.

and the WeaponPriority[x]= array, so it becomes possible to add custom weapons (Aura, Serpentine, INF, U4E, Snipers Paradise etc)

It now has 20 entries, I would recommend to set it to 128.

[TCP_Wolf]

Dynamic arrays exist only on the native level, not on script level as in newer engines.

I agree with the weapon priorities, though that can be scripted. It will require a new menu piece either way, but the present (classic) one is buggy anyway so replacing it wouldn't hurt one way or another

[HbG]

This problem is caused by client prediction, because the client knows that a non-sustained pawn in mid-air has "Phys_Falling" and thus... falls to the ground. Why the server decides to keep the pawn up in midair, though, is a mystery to me. However, since the location of the pawn does not alter on the server, the server will not send a continued "update location" to the client telling the client the pawn is still in the air where it was just the moment before... because Unreal is so "smart" to only send data that actually changed.

Why the pawn doesn't fall on the server is apperantly such a mystery it hasn't even been solved in UT2004, as i said, it's not very critical. I suppose some script can be updated to at least keep the player in midair on clients' views. They'll be combo'ed off pretty quickly that way.

Already exists... Nephthys API...

Does it parse that console command which i forgot the name of? If so it may work, but it's not pretty. Personally i think a patch should do away with uscript hacks and implement changes in the cleanest way possible. You can always include some legacy functions to maintain compatibility. IP could be stored as a const in the playerpawn, accessible through a native function like ID's are in ut2003/4, and/or given as an optional argument in the prelogin/login functions.

That said, i haven't seen the API yet.

... and why the heck are you posting this here? We have a developer board with people who specialized in such topics where you are on as well!! But no you post that here... bah

Security through obscurity is not real security. People will find out what you implemented anyway, it is the implementation itself that should be secure, not any secrecy it is based upon.
For this reason i believe this should be a public debate. Most secure authentication algorithms, like the ones used in SSH for example, are open source. In fact, closed source ones are frowned upon by proffessionals as they cannot be examined to determine how secure they are.

Also, a very pragmatic reason: I didn't have access to any admin forum at that time.

I hate localization, but that's just my opinion. In Crystal Chaos for ut2k4 it has always been more hassle than worth, and what you could do with one line of code in Unreal One suddenly required several entire CLASSES(!!!) in ut2k4? Only for localization? PFFFT!!!

For example: we have a bonus message with a variable bonus value such as....

"You just earned ..somevalue.. extra points."

If sent as text, all you do is Blah.ClientMessage(...)

With message classes, you need to send the class along with the bonus value and have the client decode both to set it back together. While the technique is clear, the effort it made to get right was outrageous compared to the result!

Yes I know it is way more network efficient though....

Just because UT200x takes 4612 classes to do the most trivial thing, that doesn't mean we have to do it the exact same way. The philosophy in UT200x seems to be to make many changes possible without changing critical classes like the gametype or pawn/controller classes, the advantages for cross compatibility with many mutators for example are obvious. Not as much of an issue for Unreal though.

I would propose deathmessages to be efficiently replicated by one class, which people can then subclass to modify any way they like without touching the gametype.

As for localisation, i embrace it and use localized variables where needed, so other people can adapt anything i make to other languages, should they wish to do so. It's a minimal effort, anyway, more of a good programming habit.

One thing that may be useful, would be some way to select a specific localisation for a string, so you can force messages to be the same across all clients regardless of their individual locale, if you really want to. So you can do something like ClientMessage( SomeString.int );

Just a dumb question, who will use features like these?? Mod writers? Certainly NOT! Because they will want their mods to remain backwards compatible...

The choice to use it should still be left to the mod writers. If you don't implement new features because noone will use them at first, we would still be using 16 bit processors with x87 floating point, too.
I really liked working with dynamic arrays and while i don't use them for everything, they're a feature of newer the newer unreal engines i really would miss.

I do see another solution however. One of the nice things about dynamic arrays is the way they're stored in ini files. Or rather, the annoying way fixed arrays are, creating a line for every element, regardless of whether it's populated or not. Just changing the way fixed arrays are stored in ini files to resemble that of dynamic ones would be a major improvement, the simplest method would just be to not write unpopulated lines, it wouldn't even break compatibility.

I still see UT2004 mods from UT mod writers who never managed to adapt, using something like 32 arrays of 256 elements to store stats. This leads to unscrollable logfiles several hundred K large, i hate that with a passion.

[HbG]

HBG,
I like many of your ideas, but I had wished you had brought yourself slightly more up to date on existing mods.

A few things from your wishlist were also started (venimous already had a grab on a http server a time ago), but overall you come with a large list of stuff all at once. Also, a few things may not belong on a publicly available forum...

Another example would be "reliable large array and string replication"... you know what's weird? 224 actually had that at least to a greater extent than 225!! And also, scripted solutions for this exist (I wrote 2 myself!).

And I very much agree with Zombie on the compatibility problems with existing mods that a few changes may yield. Just take the console thread and the "state code problem" (use the search function to find the thread lol).

Changing the "playerpawn" move functions - when needed with enhanced netcode - is probably another good idea... just too bad that for things like my "224 compatible old menues with mouse support in fullscreen mode" I was required to override some of the events there to capture mouse movement... so again I would fear other mods (not just this one from me) would have to be rewritten to accomodate such changes. Same thing as the state code console....

I wrote it all down in part for personal reference, because i know being the chaotic person i am i would easily forget half of it later. I haven't had the time to check out all the new things, but it's good to see the game is still alive. As i stated earlier, some things done in script are best done in native code, a HTTP server is a good example of that. Unrealscript would be well suited to be used in a way similar to PHP.

I also don't think every mod, nut, cranny and bolt that's nice should be included in future versions, like any new version of a game, it should be improved, but also kept basic. Leave the fancyness to third party developers.

I also agree compatibility with mods should be maintained, as many of them have been abandoned by their original authors. But compatibility with mods is a different thing from compatibility with server versions, and as i said before, features can be implemented on a "use it if it's available on the client" basis, where server admins can decide what to allow on their servers, and what not. Script is also quite flexible, things can be implemented optionally, there could be two .ini files configured with different consoles and startup gametypes, one for compatibility, and so on.
I think there are enough possibilities to both make the changes Unreal would benefit from, and keep it compatible at the same time. Just both at once is difficult.

rant rant rant... from somebody who really wrote a few things lately for Unreal... Your persecptive is mostly ut2kXX, so please bear with us Unreal One oldies. I'm afraid

There's nothing wrong with a bit of perspective or fresh air. I knew not everything of what i wrote down would be met with "Yes that's a wonderful idea". And that's a good thing. I'm just hoping to add to the discussion with the insights and perspective that i have. What is ultimately done with that, is not up to me.
Change is always met with opposition, but it's often good in the end.

After all, retrogaming isn't just playing old games. It is playing old games with today's standards in usability.

this will not hold true once it comes to IMPLEMENTING it...

Hmm, i don't get that, could you explain in detail?
Also, oneliners are always oversimplified, don't take them too literally.

[TCP_Wolf]

Already exists... Nephthys API...

Does it parse that console command which i forgot the name of? If so it may work, but it's not pretty. Personally i think a patch should do away with uscript hacks and implement changes in the cleanest way possible. You can always include some legacy functions to maintain compatibility. IP could be stored as a const in the playerpawn, accessible through a native function like ID's are in ut2003/4, and/or given as an optional argument in the prelogin/login functions.

That said, i haven't seen the API yet.

It's a C++ native mod, but you can call functions like "getIp(PlayerPawn)" from script.

Security through obscurity is not real security. People will find out what you implemented anyway, it is the implementation itself that should be secure, not any secrecy it is based upon.

Yes... you are right... I suppose that's why UCop2 was so much obfuscated

Also, a very pragmatic reason: I didn't have access to any admin forum at that time.

Are you saying you lost your login to the KDS board? Boo

I do see another solution however. One of the nice things about dynamic arrays is the way they're stored in ini files. Or rather, the annoying way fixed arrays are, creating a line for every element, regardless of whether it's populated or not. Just changing the way fixed arrays are stored in ini files to resemble that of dynamic ones would be a major improvement, the simplest method would just be to not write unpopulated lines, it wouldn't even break compatibility.

I like that one alot.

[TCP_Wolf]

I also don't think every mod, nut, cranny and bolt that's nice should be included in future versions, like any new version of a game, it should be improved, but also kept basic. Leave the fancyness to third party developers.

Perfectly right... weird thing is I see things like a http webserver in Unreal as a fancy thing. I always preferred adminning a server from in-game and when trying to do anything from inside a ut2k4 server I was annoyed at how useless being an admin in game actually is. LOL

I think there are enough possibilities to both make the changes Unreal would benefit from, and keep it compatible at the same time. Just both at once is difficult.

There you go, you found the catch already The whole "console" (if taken as an example) topic is so complicated it would fill several threads alone...

I'm just hoping to add to the discussion with the insights and perspective that i have. What is ultimately done with that, is not up to me.

Are you saying you're not going to implement anything yourself for Unreal and you just came over to load off your share of ideas? We need more developers, not necessarily more people with new (or old) ideas

After all, retrogaming isn't just playing old games. It is playing old games with today's standards in usability.

this will not hold true once it comes to IMPLEMENTING it...

Hmm, i don't get that, could you explain in detail?
Also, oneliners are always oversimplified, don't take them too literally.

Hmm... now which example can I use here... how about this one... you probably know about usaar's "oldskool" mod for UT(99) which allows you to play Unreal One in UT.

It's pretty decent, despite a few bugs remaining, and clearly very good if you want to relive single-player in UT.

As you may be aware, UTF comes with a UT build by now which also allows to play Unreal One in UT (and UTF is NOT suited for Single Player at all right now).

I originally wanted to see what usaar had done to achieve that goal because I originally had problems with a few very basic features - such as weapons not firing when being a client - so I tried to look at oldskool... I have no idea what usaar did there, no idea at all, it appeared to me that all Unreal One weapons had been rewritten from scratch! Oh and I don't even want to get started about the HUD... I understood zilch of the mod... so I had to write my own solution... Of course, my goal was code that would work with little or no change in both Unreal and UT, whereas usaar's goal simply was to write a UT specific mod that looked like Unreal One.

But still, both mods in UT don't feel like original Unreal One, they both come very close to it, but frankly, it's not the same! The "usability upgrade" - so to speak - came along with a loss, albeit a small one, of authenticity - or originality. Just play Unreal One, and both UT mods... you will "feel" it.

So the point is, if you use today's engines trying to play old games (retrogaming), you will effectively NOT play exactly the same old game, you will play a slightly different one.

[HbG]

I'm a lazy man, so i wont reply with 35 quotes this time.

KDF forums? D'oh, i thought it was here at Oldunreal, nevermind.

I didn't say i won't be doing anything beyond writing down a list of ideas, i just meant everything has to be discussed before being implemented, to be sure nothing is forgotten and everyone agrees and is aware of all the different bits that are being worked on.

UCop2, what can i say, i've learned a few things in the meanwhile.

As for retrogaming, what i meant with usability was basically cosmetic changes and under-the-hood improvements. The retexturing project and openal/opengl drivers are good examples of this, the console, hud, scoreboard and menu another. Screen resolutions have increased so much, work really needs to be done here, and then there is support for extra mouse buttons, that sort of stuff. Basically take away all the little annoyances people could have when playing Unreal on today's hardware. I didn't mean totally modernizing the game, or you might as well recreate it as a Total Conversion for UT2004, that would definitely not be my intention. Look and feel should be maintained, or the atmosphere and nostalgia drain away pretty quickly. People are also much less tolerant of bugs and glitches, being spoiled with the high quality games of today.

[asgard12000]

Hi Smirftsch

Just a minor bug.. In playsound() the multiplier to amplify sounds doesnt work
eg PlaySound(Threaten, SLOT_Talk,5.0, true,,2.0); should amplify the sound by some multiple of 2.0

Its a pain in the butt as it works in UT99, so when making u1 and UT compat mods the sounds are much louder in UT.

To make them louder in u1 i have to practically make them spike in my sound editing program or use additional slots.

Tim Sweeny's doc on sound covers it

cheers

[Smirftsch]

I'm a lazy man, so i wont reply with 35 quotes this time.

KDF forums? D'oh, i thought it was here at Oldunreal, nevermind.

I didn't say i won't be doing anything beyond writing down a list of ideas, i just meant everything has to be discussed before being implemented, to be sure nothing is forgotten and everyone agrees and is aware of all the different bits that are being worked on.

UCop2, what can i say, i've learned a few things in the meanwhile.

As for retrogaming, what i meant with usability was basically cosmetic changes and under-the-hood improvements. The retexturing project and openal/opengl drivers are good examples of this, the console, hud, scoreboard and menu another. Screen resolutions have increased so much, work really needs to be done here, and then there is support for extra mouse buttons, that sort of stuff. Basically take away all the little annoyances people could have when playing Unreal on today's hardware. I didn't mean totally modernizing the game, or you might as well recreate it as a Total Conversion for UT2004, that would definitely not be my intention. Look and feel should be maintained, or the atmosphere and nostalgia drain away pretty quickly. People are also much less tolerant of bugs and glitches, being spoiled with the high quality games of today.

I prefer the Oldunreal forums as well, using KDS as reference. People posting there collected a lot of very usefull informations, pointing many problems out but normal take not part actively in the 227 development, so i prefer the internal forum here for people who do.
For nephthys it seems it will be not in 227 because i can't implement it there, they are not giving the sources out. No way i will put a 3rd party stuff in here, not beeing able later to maintain it - aside that i want 227 as clean as possible, allowing people to run a server without adding a dozen of additional mods, protections and tools. Currently its a pain in the ass for everyone to run a server. This has to find an end. And it seems i don't need it anyway.

I gave you permissions to the internal forums a while ago, donno why you can't access it then, maybe try "update Session" in the top of the forums.

Hi Smirftsch

Just a minor bug.. In playsound() the multiplier to amplify sounds doesnt work
eg PlaySound(Threaten, SLOT_Talk,5.0, true,,2.0); should amplify the sound by some multiple of 2.0

Its a pain in the butt as it works in UT99, so when making u1 and UT compat mods the sounds are much louder in UT.

To make them louder in u1 i have to practically make them spike in my sound editing program or use additional slots.

Tim Sweeny's doc on sound covers it

cheers

Thx asgard, will check.

[.:..:]

I noticed an bug with carcass and scriptedpawns with low collisionradius and height. Like if you make an pupae with 1 collisionradius n -height and shoot it with asmd alt fire with amp it will hang the game.

The error in the codes are when small pawn spawns an gibbed carcass, the carcass "lands" on the pawn and takes damage, which makes pawn spawn another gibbed carcass which "lands" again on the pawn and so on...
Could be good idea turning on bIsBoss to True on SpawnGibbedCarcass function or disable BaseChanged damage on Carcass to stop this loop.

[.:..:]

Oh yeah I also noticed another bug in unreal engine today. This has no real protection yet (exept loaded packages scanning) so basicly anybody could use it to crash servers or at least cause terrible lags.
When you call a replicated function on a replicated actor which does not have "you" as owner, server will log on log an warning:
"DevNet: Received unwanted function '...' in '...'"

So if you do every tick call on all actors "BroadcastMessage" server log will be flooded with logs like:
"DevNet: Received unwanted function BroadcastMessage in Flashlight eldora.Flashlight0" until clients lose their connections or server crash.

So this is an kinda bad security leak which should be fixed.

[Canadian_Bacon]

soooo, hows the patch going?

[StaticNova]

right me if i have wrong but smitch something didn't get the source code...

[Smirftsch]

its Smirftsch, and i have the sources. Currently some reallife problems, and way not enough time but working on the anticheat parts...

[TCP_Wolf]

right me if i have wrong but smitch something didn't get the source code...

You are at the wrong site. For unbelievers, google for "heathens, christians, scientology, politicians" etc....

[StaticNova]

oh i believe him i mayby just forgot to read all the replys sry

[.:..:]

Since this new patched server is only for this patched clients, wouldnt it be possibly to make downloader redirections and package compression like in UT?

[Smirftsch]

actually its for older clients as well, but the discussion about this isnt closed yet- most fixes are serversided, and the server is (thanks to legend) only compatible with Unreal 224/225/226 OR 224/225/UGold - so the question would be, make it compatible for Gold or 226, but whatever decission is made it isnt really satisfying.
A complete break and making it not compatible with older version at all would be the cleanest way, but i'm afraid most people wouldnt want to update from what i've heard.

[Leo T_C_K]

Now Upak bugs.

Ugold/rtnp226 have missing explosion textures at upakexplosion effect(RL/GL).
Spriteball explosion is broken at network play on these. Sound effect on upakrocket when it explodes is not at network play. Rocket sometimes get stuck at water. Carifle animation online is bit broken. Carifle clip skin should be same like at 224. ALtGrenade skin is altered by postbeginplay function I think, basically it is supposed to look like this:
[img]http://img111.imageshack.us/img111/6290/shot01588gg.jpg[/img]

Grenade has no smoke when it is flying online.

Deafult game switching after transmission.

Marines should be set to talk always(Like at Asgard's umsspacemarines), not only at crashsitegame and they should be set to not show name:player, not appearing at f1 when hit online and also can be killed online. Only difference there can be for marinematch, so there they will appear at f1. At other gametypes not. For female marines, it can be random, like at crashsitegame, but also they must have set female pain and dead sounds.

Also there is treadsm animation at scripts, that animation does not exist, so better to replace it with treadlg for not causing problems. Also when they are waiting, they can have Look1L animation and also animation at victorydance, etc. There are unused animations at original model, so why not use it?

And it would be great if Upak will be 100 percent compatible with normal versions too, so it will no longer look to Upak.dll as it was already mentioned here.

[Leo T_C_K]

I forgot, ehm will be at next OMP or at 227 patch fixed overlaping hud problem with some rtnp and Ut weapons?

[.:..:]

Could you also add a "AddToPackageMap" function to GameInfo like in UT2004 to add serverpackages in game (w/o server restart)?
Also change Assert(NewItem!=None) to Return in "AddInventory" function in Pawn, becouse its just a pain in the ass.
Remove "BroadcastMessage" from replication in actor and somehow force to break from a runaway loop over 10000 interators instead of crash. Remove those useless "Client netspeed is.." logging and "... received an unwanted function ...".
And if it is possibly, make it configurable if scriptwarnings logging enabled or not.
Make a downloader redirection possiblity for other 227 users.
Fix a script warning in BruteProjectile on function BlowUp, it makes a warning if instigator dies before the impact...
also on NaliRabbit in state Evade, function PickDestination, if Enemy leaves the server the rabbit will start spamming on log with loads of warnings.