Carbon wrote:No, I didn't watch the demo. No need really.
So you need to explain human nature to server masters and find a coder. There are a number of people here who have the skills, but so far it appears they aren't worried or interested.
Best of luck with your mission!
Yes, lack of interest is one of main factors. What really bothers is attitude of server admins.
Barbie wrote:What about running on a moving brush? Or flying around with jets or R3? Or using relics?
Sounds not so easy any more...
I just gave basic concept.
JackGriffin wrote:It's not nearly that easy. Because of the ancient nature of the netcode and the fact it was designed to function with dial-up modems there is a metric ton of prediction code built into the engine. Want to see what I mean? You only need to simply compare a player running on the ground with an alt-guided redeemer flying over his head. The player will appear smooth and normal while the redeemer appears herky-jerky and not at all smooth the closer you look. Both the player and the redeemer are doing the same thing but there's a ton of prediction code that smooths out the player's movement so it looks cleaner.
I've plotted exact movement before on players running across an open map online. You'd think it would be a consistent velocity, however it's anything but that. Players rubber band a ton, it's just in very small increments.
Anyway I'm blathering on but I can simply say that distance-versus-time used as a rule will not work. This is due to all the fluctuations that exist in tickrate, netspeed, packet loss, etc. The best way to deal with speed hacks is to watch the netspeed of the client and poll the processor speed like ACE does. If the client is changing either of those on the fly then they need to be removed.
Yes, netcode is outdated indeed. Fluctuation is here, and I'm sure that in my case that's the main problem with my connection. Some averaging can resolve it, I guess.
How you meant that netspeed watch, and what actions to perform ? ACE indicates it, indicates tickrate too, and what is use of it ? Only that people see it. Speed differences are there. Client can change netspeed when is not connected to server.
How can server poll processor speed of client ? That can be fooled easily on client side, I'm sure.
sektor2111 wrote:It would be a hard work for tracking everything. ...
Given the new way of power saving and hardware features from nowadays, this old engine has to be rewritten... BY WHO ? Because it looks like this new hardware architecture makes life harder for old software a la UT.
Who is in charge to do this in legal terms ? Yeah, a wreck still hangs on copy bullshit stupid rules from Ice Age... Nobody ? Reason ?
If a new UE1 will be coded, a lot of players will quit playing more or less borked versions and will return to UT99 - I can bet on that. And if Editor would be a bug free one... I will not wanna know the number of UT99 players in future - but this is at dreaming stage...
Well, as client computers gone faster, server computers gone too. There should be enough power for all necessary calculations, trackings.
Doing new UT99 would be nice thing. Actually, it is done already in couple cases. So, we have so called multi core release, what resolves some speed problems - for instance it will not run faster offline with V-sync off. Or will be not too fast online with it - funny thing is that one admin pointed on it to me (I knew about it for years, but did not use it) .
So, we actually already have UT99 with proper speed control (may be not 100% in all cases, I did not test it much), and we are back to what is told here already: how to make people using it, and more important: how to check is it what really running ?