helping ppl to set up r1q2ded

Da^JuaN · Post by **Da^JuaN** » Thu Nov 25, 2004 1:15 pm

Already pointed Pain at it, to update it.

angra · Post by **angra** » Thu Nov 25, 2004 2:12 pm

I still see the 1788 on your servers, angra, huh?

Now its done

n99 · Post by **n99** » Thu Nov 25, 2004 7:15 pm

I'm getting this alot on the servers running R1QD, had it before I think, thought it was map-related, since it happened in time, but I have had it in at least five different maps on DA Main now. I'm course not certain it has got anything to with R1QD.

Something like this

UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
..

stan0x · Post by **stan0x** » Fri Nov 26, 2004 12:50 am

i had that 2 :S

Da^JuaN · Post by **Da^JuaN** » Fri Nov 26, 2004 6:00 am

n99 wrote:I'm getting this alot on the servers running R1QD, had it before I think, thought it was map-related, since it happened in time, but I have had it in at least five different maps on DA Main now. I'm course not certain it has got anything to with R1QD.

Something like this
UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
UREMOVE OLDNUM != NEWNUM
..

ive to say i had it to when i was using nc 2.40.. not when i was using 2.34. Now i switched to AprQ2 and im not having it anymore.

R1CH · Post by **R1CH** » Fri Nov 26, 2004 6:57 am

The "UREMOVE OLDNUM != NEWNUM" is caused by r1q2ded cutting off the packetentities early. Basically there are too many entities or too much activity in one area of the map, and the packet sent to your client would have been greater than the maximum size allowed. When this happens with normal q2 server, the packet is dropped and your client will experience "freezing" where you don't appear to be moving but in reality you are, you don't see any other entities, etc...

r1q2ded cuts off the packet before it's full and sends what it has anyway in order to avoid this freezing effect. However some clients will print the "UREMOVE OLDNUM != NEWNUM" warning since they are expecting data to be there when it is not. This is a fairly harmless warning and can be fixed by using a client that hides it

.

Occasionally though during very heavy activity, some important entitiy updates will be lost and you will begin to see strange artifacts such as teleporter trails on players, flying gibs, etc. To fix this, simply exit and re-enter the area of the map where the problem is if possible.

NRGizeR · Post by **NRGizeR** » Fri Nov 26, 2004 7:08 am

So if I read that correctly, it IS map dependent, but also client dependent. I mean, if you build a map with small areas, and a low number of entities, you won't be getting this error since entities will be kept to a minimum. If you're not 12vs12 in an area that is

Which entities will NOT be included in the net packets? (I assume that they would have been so smart as to not bother the server with entites that could be handled client side, but which ones are those? I would guess that target_speaker would be one of them?)

Just wondering to see which entities to be careful with

R1CH · Post by **R1CH** » Fri Nov 26, 2004 8:01 am

It isn't selective - it just fits as much as it can starting from entity 0 and proceeds until the packet gets too big. I may try and re-order it sometime, but this is a function that runs very frequently for every client so I want to try and keep it as fast as possible. Map objects like target_speaker aren't a concern as they will get baselined anyway. It's entities created in game - players, gibs, etc that are the problem.

It's map dependant as of course a large PVS will have more entities. Maps like urban where the entire map practically is one big PVS will likely be a problem. Any map with large open areas that see a lot of activity will likely be an issue.

NRGizeR · Post by **NRGizeR** » Sun Nov 28, 2004 3:28 am

R1CH wrote:It's map dependant as of course a large PVS will have more entities. Maps like urban where the entire map practically is one big PVS will likely be a problem. Any map with large open areas that see a lot of activity will likely be an issue.

So basically the mapper can't do anything more than intelligent VIS blocking, right? Does the standard 3.20 Q2 remove those messages? Because I've never experienced them on ANY map (ever)... or is it just that I haven't been on a server with enough players? (6vs6 max)

R1CH · Post by **R1CH** » Sun Nov 28, 2004 12:31 pm

Good mapping should pretty much solve the problem. I'm really not sure how it can occur on AQ2 as I thought that there weren't that many entities in a standard game.

Compare it to the Q2 Gloom mod where there are sometimes 30+ players on a server and wide open areas with structures from each side, gibs, projectiles, dead bodies, infestations and other ents and still the problem doesn't occur, you have to wonder what on earth AQ2 is doing

.

You won't see those messages on a 3.20 server, but if you use 3.20 on an r1q2ded server you likely will. Q2 3.20 server doesn't truncate the packet if it gets too big - it simply throws it all away, leaving your client without ANY data for the frame - often causing you to feel 'frozen' since the updates about your position are getting discarded too.

Ideally the best solution would be to spread the entities out over several frames worth of packets, but that would require fundamental changes to how the q2 netcode operates. It's on my todo list though

.

Stric · Post by **Stric** » Sun Nov 28, 2004 12:33 pm

R1CH wrote:It's on my todo list though .

Is your todo list big?

NRGizeR · Post by **NRGizeR** » Sun Nov 28, 2004 12:43 pm

R1CH wrote:Good mapping should pretty much solve the problem. I'm really not sure how it can occur on AQ2 as I thought that there weren't that many entities in a standard game.

Good mapping being what? good VIS blocking? Low number of entities?

R1CH wrote:Compare it to the Q2 Gloom mod where there are sometimes 30+ players on a server and wide open areas with structures from each side, gibs, projectiles, dead bodies, infestations and other ents and still the problem doesn't occur, you have to wonder what on earth AQ2 is doing .

So how would you then be able to solve it thru good mapping? If you just said that only entities like players, weapons, gibs, etc are casusing the packets to increase in size, and still the error won't show up in game that has 30+ players visible in one area, how could a mapper for AQ2 solve this if it turns up even with sub 15 players? Even a map that would have no PVS would "see" less entities than the Gloom map with 30 players in one area, right? What am I missing?

R1CH · Post by **R1CH** » Sun Nov 28, 2004 1:15 pm

Good mapping being good vis blocking and low number of entities where possible. As I said I'm not sure why AQ2 would generate such a problem as from what I've seen there don't appear to be too many entities on AQ2 maps like items, gibs, etc. Even Q2 deathmatch probably would have more in my opinion. This could be due to a bug in AQ2 or similar. If you have a server or map where you seem to experience it most, please let me know so I can join and figure out just what is filling up the packets...

n99 · Post by **n99** » Sun Nov 28, 2004 2:13 pm

It happens all the time, from now on, I'll pay attention where I'm playing, what the player load is, what map I'm on, and where I am in the map.

angra · Post by **angra** » Wed Dec 08, 2004 3:43 am

Offtopic:

R1CH do you have any plans to add some anticheat stuff?