Jump to content

Recommended Posts

Is there a plan to reduce lag in future version of 0 A.D.?
In my opinion lag has increased in last 3 version of 0 A.D. .

Share this post


Link to post
Share on other sites

Depends on what kind of lag youre talking about. Simulation lag not really. Network lag is a thing you have to discuss with your ISP. Less FPS can be a result of the FPS limiter which was implemented add the new models with more polygons, new maps with more actors.

There was the multi-selection patch and the visual aura thing which might have had an impact on the FPS when selecting hundreds of units. I didn't really notice a difference.

  • Like 1

Share this post


Link to post
Share on other sites

I mean network lag. Since alpha 18 or alpha 19 (my first version was alpha 16 / 17) game is lagging more and more.

My ping is surround about 55ms:

pg.PNG.54fc192b7d7e52b2e9f57b6a3566863c.PNG

 

I think the IPS isnt the problem, the network engine (by design) of 0 A.D. is the problem, i think.

There are many data sended betwenn all clients.

Execuse me for my english, i am from Germany and my english isnt the best!

 

In newest version the game lags (often) in early game, in earlier versions of 0 A.D. the game lagged, if any, in late game (caused by too much units).

But currently it also lags in if you start the game (~15 units / player). So many players leaved 0 A.D.

 

In my opinion there are 3 solutions for this problem:


1. introduce seperate lobbies for different continents

It isn't an good idea, if an player from america plays with people in europe. Its also nice, but this causes more lag, because the route is very large. It will be an better idea, if americas plays with other americans and europe players with other players from europe. So we will prevent some lag and less bandwidth. Other games (like League of Legends or World of Warcraft) does also seperate regions to reduce lag.

 

2. 0 A.D. is hosting games itself

I think this option isnt possible, because of its financial price.

 

3. Redesign Architecture of Network Engine of 0 A.D.

Think about an new architecture of network engine, which will reduce neccessary bandwidth and uses more prediction. Also dont send all units and synchronize all units between all clients. Server is chief and sends only neccessary data to clients. So not every client is simulating every game anymore, server is only the big simulator and clients do only prediction.

This can maybe increase cheating, its possible, i think. But it will also reduce lagging in many times, because bandwidth usage is lesser.

Edited by JuKu96
  • Like 1

Share this post


Link to post
Share on other sites

I don't have such a problems, but maybe the experience differs from a connection to another.

  1. Whenever we get the numbers of League or WoW we should do that for sure if we don't want to get crazy on lobby hah
  2. Will be the same, but on the other hands I think devs are working on a standalone dedicated server executable
  3. Won't this solution add bandwidth usage? Clients still need to be synchronized in order to play the game properly (I am not an RTS expert though)

Share this post


Link to post
Share on other sites

@Dade  Thanks for your answer!

 

1. Yes, but maybe also yet to reduce lag.

 

2. A standalone dedicated server executable sounds nice! :D

 

3. No it dont will add bandwidth usage. Currently every 5 or 10 ticks all units are synchronized to detect OOS. But if server is chief there cannot be an out-off-sync anymore, so detection is redundant and traffic can be reduced.

Edited by JuKu96

Share this post


Link to post
Share on other sites

A dedicated server won't really help with network lag, nor with clientside simulation or graphics bottlenecks. The feature was mostly needed when only few people could host. It would also play a role if Wildfire Games would host rated games - but then the wfg would also have to simulat the games and not only proxy the commands, as the clients could otherwise claim to not have lost without disconnecting, evading the rating reduction again.

Share this post


Link to post
Share on other sites

@JuKu96 the person just above you was working on it. He doesn't anymore, because that doesn't make much sense since STUN has been implemented. It wouldn't make the game any faster any way.

Share this post


Link to post
Share on other sites

Ah! thanks for this information!
But i think an dedicated server is also an nice feature - independent from STUN.

In Germany most routers doesnt supports STUN by default.

Share this post


Link to post
Share on other sites

Because it only allows someone to host who can already host, it defacto is a toy feature unless we rent a new server and host games ourselves.

Readers of the ticket might also notice that prior to implementing a dedicated server, it would also be required that players can setup the game (as currently the first player to join the server is considered the controller of the gamesetup, yet the first player can leave the session without closing the server.)

Share this post


Link to post
Share on other sites

There's some way for playing a game, that if the original hoster leave, allows you to continue to play? It would be very difficult to implement?

Edited by av93

Share this post


Link to post
Share on other sites

If the game is hosted by a Wildfire Games server, then every player could leave.

Alternatively host migration, but that is also turning the code upside down I believe.

While we're requesting improvements to the networking code to reduce the lag, we really need #3700. :-/

  • Like 2

Share this post


Link to post
Share on other sites

The last word wasn't spoken there and the patch will be needed sooner rather than later. I was just fed up with running in the review hamster wheel for more than a year without getting to code something on my own. Luckily the NetClient code isn't really coded at and if, is easy to rebase, so it should be considered postponed. (Also had some joys trying create a custom ScriptInterface for XmppClient, but I aborted because it only segfaulted :S)

  • Thanks 1

Share this post


Link to post
Share on other sites
On ‎17‎/‎10‎/‎2017 at 1:10 PM, JuKu96 said:

Is there a plan to reduce lag in future version of 0 A.D.?
In my opinion lag has increased in last 3 version of 0 A.D. .

In my opinion nope. and depends some things like maps.

Share this post


Link to post
Share on other sites
12 hours ago, elexis said:

While we're requesting improvements to the networking code to reduce the lag, we really need #3700. :-/

Currently the net client isnt running in an seperate thread? :o

This means 0 A.D. is only single threaded?

 

12 hours ago, stanislas69 said:

Too bad @andy5995 had to give up on this...

Why? What do you mean?

 

11 hours ago, elexis said:

The last word wasn't spoken there and the patch will be needed sooner rather than later. I was just fed up with running in the review hamster wheel for more than a year without getting to code something on my own. Luckily the NetClient code isn't really coded at and if, is easy to rebase, so it should be considered postponed. (Also had some joys trying create a custom ScriptInterface for XmppClient, but I aborted because it only segfaulted :S)

If you want i can also help to make this single threaded game an little bit more multithreading. I have an little bit of experience in that.

But the engine isn't documentated really well (for me), so its very difficult to get started into 0 A.D. development.

Share this post


Link to post
Share on other sites

@JuKu96 It's not really single threaded. But some of the big stuff AI, Pathfinder and NetClient are running in the same thread.

Well life caught him back and he now has other priorities than to work on the best RTS to date.

@JuKu96 You could try starting off were Andy left the patch. See what he did analyse and then fix it and port it to code.wildfiregames.com. that would lift the task from elexis shoulders. As someone who has been here for 6 years trust me the hardest part is not contributing. It's starting to code. Once you breach that barrier things start to get easier. I didn't even know I could do big patches or C++ before then. About documentation. we are improving it slowly by enforcing jsdoc and doxygen.

Edited by stanislas69
  • Like 2

Share this post


Link to post
Share on other sites

Wasn't the AI is in a separate thread? At least it has its own ScriptInterface and can't interact with the simulation, thus has to copy half the gamestate around frequently.

The NetServer is running in a separate thread (which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that).

3 hours ago, stanislas69 said:

Well life caught him back and he now has other priorities than to work on the best RTS to date.

(Mostly because I didn't spent further time on trying to figure out why and where it segfaults.)

4 hours ago, JuKu96 said:

This means 0 A.D. is only single threaded?

As Stan said, the entire simulation and the entire renderer are in the same thread. These two should be split and the pathfinder should run in a separate thread ideally. Needs considerable rewriting though (the current pathfinder approach is to compute paths consecutively afaik).

4 hours ago, JuKu96 said:

If you want i can also help to make this single threaded game an little bit more multithreading. I have an little bit of experience in that.

The NetClient issue itself shouldn't be too hard to solve. One only needs to modify that one file to work the same wa as the NetServer (pushing things into a queue from the main thread, then letting the NetClient thread pull things from that queue and process the data just like before). andy created the queues already, so it just needs some testing and figuring out as to why this segfaults somewhere (probably some scriptinterface registration thing).

Share this post


Link to post
Share on other sites

No, the AI was designed to be threaded, however apart from the infrastructure for that being there nothing was done (somewhat to make debugging easier, somewhat because nobody got to that).

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Quote

As Stan said, the entire simulation and the entire renderer are in the same thread. These two should be split and the pathfinder should run in a separate thread ideally. Needs considerable rewriting though (the current pathfinder approach is to compute paths consecutively afaik).

Not that much actually pathfinder was designed to handle paths concurrently but that requires some changes. https://code.wildfiregames.com/D14 worked, but I needed to copy data for the short-range pathfinder too iirc.

  • Like 3

Share this post


Link to post
Share on other sites

thanks for all this answers! :)

Really interesting!

 

On 29.10.2017 at 12:02 PM, stanislas69 said:

@JuKu96 It's not really single threaded. But some of the big stuff AI, Pathfinder and NetClient are running in the same thread.

Well life caught him back and he now has other priorities than to work on the best RTS to date.

@JuKu96 You could try starting off were Andy left the patch. See what he did analyse and then fix it and port it to code.wildfiregames.com. that would lift the task from elexis shoulders. As someone who has been here for 6 years trust me the hardest part is not contributing. It's starting to code. Once you breach that barrier things start to get easier. I didn't even know I could do big patches or C++ before then. About documentation. we are improving it slowly by enforcing jsdoc and doxygen.

 

thanks! Where can i found his patch? I have seen you have migrated to Github? Or is current code already in SVN?

I will try this. The only problem is, that my c++ skills are currently an little bit rusty. But i think i can do it.

Do you use an networking library or does 0 A.D. use normal C++ networking?

And yes, the hardest part in 0 A.D. is to start coding...

 

On 29.10.2017 at 3:42 PM, elexis said:

Wasn't the AI is in a separate thread? At least it has its own ScriptInterface and can't interact with the simulation, thus has to copy half the gamestate around frequently.

The NetServer is running in a separate thread (which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that).

The NetClient issue itself shouldn't be too hard to solve. One only needs to modify that one file to work the same wa as the NetServer (pushing things into a queue from the main thread, then letting the NetClient thread pull things from that queue and process the data just like before). andy created the queues already, so it just needs some testing and figuring out as to why this segfaults somewhere (probably some scriptinterface registration thing).

 

"which sometimes leads to funny situations like the host losing the connection to his own server while the others can observe and chat about that"
I have also observed such situations. But why? If net server is only in another thread of same process, their isnt any connection between host and main client, or am i wrong?

I will look into code...

Edited by JuKu96

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×