Psycho wrote:What problems do you get coz?

Sometimes my shots don't register, other players don't play any sound while firing, I seem to die after getting to cover (as if I got shot through a wall) etc, weird stuff.

Admittedly I don't know enough about networking to justify >10k; it just seems to be the only variable other than possibly the large amount of mutators. That said, it may have just been been GD screwing up again though, because it was absolutely fine when I played there yesterday

0augs shouldn't suffer too much since augs have lot more traffic going on, but I suppose you did check your netspeed to verify that it was configured normally?

In UT netspeed values of around 8000-10000 are often considered optimal, I myself on my 1mbit line never really went over 10k, but biggest problem with our servers is that while Engine is relatively identical to the one UT99 uses, the amount of traffic necessarily isn't. Regarding any DXMP specific optimization I'd like to hear knowledge over theories, at this point, but feedback provides solid data as well.

Since you play from UK and the server is in your country, and I play on relatively crappy estonian 1mbit line, I'm bit surprised that I haven't really experienced the kind of problems you describe. In THC server I routinely get packetloss and ping spikes to 200 though, but that seems to be the case for past month or two mainly.

Your problems that you describe would be likely if we hosted 100 tick rate full server as then the netspeed likely should exceed 10k and even then likely result in some kind of problems.

However.. if your connection cannot keep up with your set netspeed, *then* those problems appear, too.. and raising netspeed value only worsens things as packets go nuts. Sometimes with those symptoms it is the lowering of netspeed that might help, too.

I am not necessarily trying to defend capping netspeed to 10k as it was just means of blocking half of the speedhacking problem, but I'd like to see some math about the need for higher netspeed values before I fully buy it, I think.

Let me explain what I have learned and noticed over the years of playing DXMP, doing server side optimizations, and even scripting mods with net optimizations.

DX is based on Unreal Engine, which was made in 1998. Back in 1998, not many players had cable, DSL, most of them used 56k modems or similar slow connections. Bandwidth usage was big issue for any kind of gaming back then. Games couldn't afford sending and receiving anything larger than 8kb/s, because that would completely fill their connection resulting in high pings and lag.

Now, to completely understand the issue, we need to study how game networking actually work. All actors in game can be replicated or not. Being replicated means, that there is some communication between player and server about that actor (opened channel in stat net). When designing MP game or mod, you need to make only actors that really NEED to be communicated between player and server, to be replicatable. All other actors should NOT be replicatable. Every additional actor will cause more bandwidth usage and more net utilization and if that is not needed - get rid of it.

So, which actors do truly need to be replicated then? Obviously, first one is Pawn of the player. Then, weapons, and pickups. Glass that breaks when being shot? Yes - if you don't replicate them, then shooting glass will not be seen to other players. With this information, imagine UT game. What is replicated there? What I counted here. So, for each player, around 10 actors if he is stacked with all weapons plus about 20 actors as being pickups on map. Anything else? Not really. 10 players in server means 10*10 + 20 = 120 actors. And these are NOT constantly replicated to all players. Unreal engine has optimization - relevancy of replicated actors. If the actor is not relevant as if not being visible eg. being on other side of the map - why bother replicating it? So, in UT game, there is approx. max 40-50 actors being replicated to each player - in fights!

Let's take a look @ DXMP now. DX was first SP game only. And it was scripted that way. SP scripters never considered DX being MP game once, so they were doing BIG optimization flaws - that is - creating new actor for every "peace of metabolic end product". Every aug is actor, every skill category is actor. This is NOT needed at all. These augs and skills could be simple objects only and not actors. When extending DX to MP, actors for augs and skills stayed. And what is worse, these actors are all being created uppon login whether player actually gained any or not yet. How many augs DX has? 20. And 10 skill sets. Plus aug manager actor and skill manager actor - Are you counting? That is more than 30 for every single player!

DXMP has also other stuff UT doesn't. Furniture, barrels, more pickups, more movers. Instead of usual 40 actors being replicated to each player, in DXMP, there are 200 or more being replicated.

Another crucial mistake original scripters did are visual effects actors. Yes, we do need visual effects to be actors (because they fly around, are destroyed over time etc), but they SHOULD never be created on server and then replicated to players. Yes, it is easier to make such code, but it is hogging servers performance like a bitch. Imagine - all bullets, shellcasings (in AssaultRifle like 5 per second?), blooddrops, and all various visual effect metabolic end product which is NOT needed for proper gameplay at all. All this is created on server as actor and then replicated. These visual effects only need to be unreliably informed to players to be spawned on their side only. Nothing more.

I hope you understand now why, there is still no servers CPU able to host 32 players server in DXMP (when not using latest miniMTL) - so many actors creation and destruction being performed during fights that CPU utilization goes exponentially high with growing number of players.

Actor spawning and destruction causes additional bandwidth utilization.

DXMP creators back in 2000 needed to reduce bandwidth usage - because game was completely unplayable for modem users. Instead of fixing these replication issues I mentioned, they did something else awfully wrong - they modified movement code - so players weren't updating their position so often (upload saturation is the main issue of high pings and lag). Unreal engine has movement code made completely in scripting language. I compared UT movement code with DXMP and figured this out. In my CBP mod (base for AvsH mod), I commented these lines out - and guess what happened? No more movement jittering and lag that we were so used to (I am sure that you have noticed how in DXMP, your movement is constantly being "corrected" for a bit). It is true, that upload in stat net doubled or even trippled, but like I said, who does still use 56k today?

The community back in around 2006 or 2007 wanted to improve gameplay of DXMP, because large portion or maybe even all players already got better PCs and faster net connections (cable, DSL), probably noone used 56k anymore. There was one guy named DestroyerZero who was acting really smart, like he knew everything, but in fact, he was a total phonie and newb. He was saying that the issue of all DXMP net problems were in native library IpDrv.dll (when in fact this library has hardly been changed by DX creators) - it is probably 99% same as in UT game. DestroyerZero recommended upping TickRate. And so servers started using 60 tickrate, sometimes even 100. In UT, even 40 is considered high and only recommended for top servers. In DXMP is no different - if you want smooth gameplay, just scripted net code has to be fixed, nothing more.

As for netspeed. I strongly advise you to use max value - 20000. Why? I am sure your connection can handle 20kb download and 20kb upload or no? If yes, there is no reason to use lower values. Lower values would just cause bandwidth saving, when this is not needed at all and reduced online gaming experience.

It is true that netspeed is somehow linked to framerate. This is certainly engine issue and I have no idea why these vars are linked.

Technology changed so much in 13 years that different approaches need to be used these days. Bandwidth saving is not so important anymore - we only need to target for better gameplay performance, smooth, low ping, quick responses and even if we have to sacrafice larger bandwidth utilization.

Deja Vu wrote:It is true that netspeed is somehow linked to framerate. This is certainly engine issue and I have no idea why these vars are linked.

I notice in another game that when connection is bad, fps can be very bad and even worse when there is a lot of sound demands. That could be something to do with the distance between actors, not being in the same zones, or I feel it has something to do with sounds being activated, which causes a momentary freeze of the game screen.

Great information right there. There is no point in defaming DZ to that extent, though, but I can see the source of irritation.

However, regarding FPS cap relation: Unreal Engine 1 games seem to have their game speed broken at 200 FPS (confirmed, but lower 100 fps seems to accelerate some things as well), and it seems that the maximum available default net speed for DXMP actually capped the game under it? It is clearly a problem if the game does not run at the pace it was designed for, so could be that the UE1 devs simply took that route to cap it? As to why lower netspeed values cap to lower frame rates, no clue.

I would like to ask your permission to post your lengthy post on my clan website, next to other tutorials and articles. It is not often that reliable information about DXMP can be obtained.

Also, I don't know if you are aware of it yet, but competitive gaming is completely broken in DXMP due to issues UE1 has with "new" hardware. I have hard time helping even closest friends with it who are actually interested in fixing it.

Surely an informative post but meh.. tl;dr

synthetic wrote:Great information right there. There is no point in defaming DZ to that extent, though, but I can see the source of irritation.

However, regarding FPS cap relation: Unreal Engine 1 games seem to have their game speed broken at 200 FPS (confirmed, but lower 100 fps seems to accelerate some things as well), and it seems that the maximum available default net speed for DXMP actually capped the game under it? It is clearly a problem if the game does not run at the pace it was designed for, so could be that the UE1 devs simply took that route to cap it? As to why lower netspeed values cap to lower frame rates, no clue.

I would like to ask your permission to post your lengthy post on my clan website, next to other tutorials and articles. It is not often that reliable information about DXMP can be obtained.

Also, I don't know if you are aware of it yet, but competitive gaming is completely broken in DXMP due to issues UE1 has with "new" hardware. I have hard time helping even closest friends with it who are actually interested in fixing it.

What I really don't like is when people pretend to be smart, but in fact, they are dumb or just wannabe smart and spread lies that affect many people. Back then, when I though that DZ had some serious knowledge about DXMP, I believed DXMP was performance-wise lost case and never to be able to be fixed. If he told me that DXMP only needs better scripting, I would study scripting back then already and do what I did several years later with miniMTL. Community could have had miniMTL with spectator mode much sooner and the community would be bigger these days...

Sure you can quote my post on your website. What is published on internet is considered public anyway.

2 years ago, everything hw related wasn't issue for my DX game. It is true, there were some additional files needed and some configuration tweaking, but at the end it worked fine. Sadly, the game doesn't come out with these fixes...

If it is any help Cozmo...

I got halfway through mapping Hengsha, when I felt the best thing was to scrap the brushwork completely and start again with a different rationing and usage of brushes. I did use actors a lot, thanks to Chinny, Atrey and others, but what I found is that while you can have a lot of actors in one area without any real problem, when a mass of them comes into player view then you have a problem, seemed like only 20-30 railings per player view was possible in addition to everything else.
I notice on FT, Face did this, he "scrapped" most of his city and started again and the results were really worth it.

Also I think this actor stuff is quite important. People will play old graphics no problem, but when performance is also affecting gameplay, that's where people have a reason to find something more enjoyable.