[Makeurtgreatagain]

so long as the clients behave AND Everybody is ENFORCED to use exactly the same net settings
it functions beautifully at 60snaps

what aggravated the issue wasn't so much a quirk of idtech3 so much as it was clients not behaving and having very unstable connections

idtech has poor tolerance for packet-loss and jitter and the faster you run it the worse the tolerance is

on a modern connection on a modern machine connection to servers that are in your region its a non issue
don't do any of that and it all goes to hell and it does the same thing at 20snaps its just far more tolerate of total shit connections at that slow of a rate

net-settings including rate need to be enforced and set automatically by default this eliminates the problem of people failing to configure there net cvars or monkeying around with them when they haven't a clue what they are doing

something I keep bringing up and something that doesn't get implemented for whatever asinine reasons

This post has been edited by Makeurtgreatagain: 13 May 2017 - 01:29 AM

[nxu|Achsenknopf.---]

I ported your code to nexunity servers. It's running fine there for some days.
A negative impact could not be noticed. SV_Frame is constantly called 20 times a second instead of 100-600

nexunity.org:27960
nexunity.org:6000
nexunity.org:6001

This post has been edited by Achsenknopf.---: 14 July 2017 - 09:54 PM

[karnute]

Achsenknopf.---, on 14 July 2017 - 09:53 PM, said:

I ported your code to nexunity servers. It's running fine there for some days.
A negative impact could not be noticed. SV_Frame is constantly called 20 times a second instead of 100-600
nexunity.org:27960
nexunity.org:6000
nexunity.org:6001

Thanks a lot for testing.
I feel your server has now less frequent and shorter yellow spikes in upper part of lagometer than before. Yellow bars in upper lagometer are extrapolated frames (sync lost from server), that is coherent with less calls to SV_Frame, but mainly means that the server needs many less checks to send unnecessary packages to clients that are not going to receive them on time anyway, and it is sending only on-time packets. It is very significant, especially in a server so populated with 32 slots, and usually with many players from long distance (with high pings).

[travmon]

Test Servers Classic TDM karnute source and ctf NorthEast karnute source Here are client binary's

This post has been edited by travmon: 19 July 2017 - 06:16 PM

[Makeurtgreatagain]

@Barbatos is this going to make 4.3.3 ?

most people I have talked to agree this should at least be a option either via cvar or seperate server binary

also unlock the cvar default it to 20 and put a danger will robinson on it

I test this on my personal server a 5 dollar a month duel core xeon and there is a marked improvement

the argument stands that people that have and (I use this term very loosely)Decent connections should not need to be at a disadvantage to people with connections that can barely manage to load google.com, its a matter of by modern terms UrT requirements are astronomically low ... if you don't meet them you should probably hang up your mouse and keyboard,and get a job or take steps to join us in the year 2018 .. or at least 2010 ...

This post has been edited by Makeurtgreatagain: 13 January 2018 - 10:23 PM

[travmon]

Makeurtgreatagain, on 13 January 2018 - 10:16 PM, said:

@Barbatos is this going to make 4.3.3 ?

most people I have talked to agree this should at least be a option either via cvar or seperate server binary

also unlock the cvar default it to 20 and put a danger will robinson on it

I test this on my personal server a 5 dollar a month duel core xeon and there is a marked improvement

the argument stands that people that have and (I use this term very loosely)Decent connections should not need to be at a disadvantage to people with connections that can barely manage to load google.com, its a matter of by modern terms UrT requirements are astronomically low ... if you don't meet them you should probably hang up your mouse and keyboard,and get a job or take steps to join us in the year 2018 .. or at least 2010 ...

I think this code has issues. I gave up on these tests not long after starting. On all my tests with different compiles on different operating systems, server seems fine empty or with bots. as soon as a real connection enters CPU spike's to 80-100 % . I moved all my tests to ioq3 1.36 with fork from mickael9

[Makeurtgreatagain]

travmon, on 14 January 2018 - 02:31 AM, said:

I think this code has issues. I gave up on these tests not long after starting. On all my tests with different compiles on different operating systems, server seems fine empty or with bots. as soon as a real connection enters CPU spike's to 80-100 % . I moved all my tests to ioq3 1.36 with fork from mickael9

I have had no such issues on my xeon vps even with 18 players@60 cpu usage was ~20%
but I patched it on a clean ioquake 3 fork I did notice it was tied to Sys_Milliseconds

which it should be on its own timer and if you are running granularity or hpet COULD cause it to chew a bunch of cpu because its running faster then it needs to, should be moved to its own timer loop, we investigated isolating the entire Sys_+ timer routines for the original version of SACC but, it didn't matter enough at ~60 snaps

This post has been edited by Makeurtgreatagain: 14 January 2018 - 04:31 AM

[wTf|beautifulNihilist]

I'd love it if we could figure this out.
SACC was the best Urban Terror ever played.

[Makeurtgreatagain]

SACC was just having the higher-tickrate this is something different

to many laggots with there shit tier connections complained so they relocked it (epic face palm)

it does use more cpu at 20 snaps because its having to wait longer between iterations so its effectively burning cpu time,let it burn cpu cpu power is cheap vps's are cheap a recent xeon isn't going to balk at running 20 year old quake 3 with the timer running in step with the snaps which is what this patch does

@Barbatos

I say just keep the god dam sv_fps cvar unlocked let server admins decide what they want
its not like running two servers is a problem can run one 20 server and one 60 leagues with 5v5 would especially benefit from having it

if you are losing enough packets where you can't handle running quake 3 at 60 snaps then you should probably get off the internet \

no other quake 3(COD,Trem RE:Actionq3,Quakelive) based game on the planet seems to have a issue with accepting the fact that people with shit connections are going to have a shit experience but no here in UrT people with good connections are expected to have the shit experience, and deal with what I consider cheating which is craptacular players with craptacular connections being near unkillable because the tick is so slow.

the most 'vocal'(and by vocal I mean stupid) players that complained where people that were suddenly getting pasted, because they had zero hits and tons of antilag/prediction induced jitter. or didn't brother to correctly configure there cl_maxpackets and rate <-- this is huge at 60 snaps

because suddenly ANYBODY with a decent connection that shot in there general direction absolutely wasted them, in most cases they never even saw it coming they were just BOOM DEAD,because the netcode was doing its job and for once in 15 years and there wasn't any shenanigans with positional tracking on the server

I say *@!# yea to that because thats the crap people have to deal with at 20 snaps. when they are unhittable and sending bullets around corners or jumping up and down like a coked out bunny rabbit spraying everybody in there path

before somebody makes the argument about how everybody has a right to a fair game, re-read this post a couple times let it sink in

so what you expect unreal 4 to handle that packet loss any better LOLNO its going to be just as bad, if not worse because client prediction, if also played UT4 it warps more then a trek marathon at the slightest touch of a connection quality issue

This post has been edited by Makeurtgreatagain: 20 January 2018 - 06:59 AM

[FS Frankie V]

Well net experience is going to be different in UrT5 as a lot of the important stuff is managed on the client that use to be managed by server. Epic promises no more magic bullet shots around corners and the position of the player on the client is where they are.

A bit of interesting info though is Urban Terror 4.X is still and will always be a mod of a game called Quake 3 and based on the terms and conditions of the EULA UrT HAS to be backwards compatible under idtech3 as to the selection of the game engine and the supplied game code.

What this means is the end user is not required to use the engine that FS provides and only does so as a means of convenience as to ease of installation and the end user does not have to run around looking for a preferred engine. If one wants to try a different engine then they are free to do so but FS has a responsibility to ensure a level playing field so playing around with netcode is a rather touchy area.

The requirement of the two raises an interesting question in that FS is at the very least responsible for fixing critical bugs as far as the game code goes but as far as the engine goes how far should FS go as far as official bug fixes and patch work?

Top of the list is to patch exploits and bottom of the list is updates that would be assumed to be an improvement and so called improvements like netcode is on the bottom of the list as the one time such an "improvement" was made the result was a disaster.

The main issue was not so much a client problem as it was a server issue of individuals running a server on a home brew server of less than ideal specifications and worst running on a single box that they do their day to day work on.

A good example as to proving this issue is Barbie use to run a temp server on his home box and ever time he would compile some code work the average ping of 250 would jump to 999.

Soooo

The main issue is not one of a bonked netcode but one of stability of the specification of an unknown server.