Lag

[euphoria]

There will allways be lag on the internet, but bad code is often the reason why it's so noticeable.

We will allways have some small delays on boats positions, wich means your opponent is a few meter further ahead of what he appears to be. We can live with that. But what is not necessary is to slow the client boats down due to lag to the host. The speed/acceleration of the boat should be calculated from the wind information your local pc only! In the present version of vsk, it's far from the case... Your boats speed/acceleration is calculated with wind information from the hosting boat, which is not in accordance with the wind you see on your screen.

This is the reason why the Maria Island course is the best lagwise, and waiheekee is the worst. The wind is much more stable at the Maria Island, while it's full of strong gusts with variable wind direction at waiheekee. This means you slow down when you sail onto a gust which only appears on the hosting machine (at that time).

[o2]

Thanks teacher !!

Excuse me I should have said MASTER

[Guest]

Now, that is great insight! :biggrin: Have you guys taken this thing apart? :v-smile:

[No Match]

If the weather are to be run independently on each participants computer how do you syncronize the weather on each computer?
Can it be done by handing out two sets of numbers to the computer of each participant in a race on login?
One number that define what kind of weather is to be put on, and another one that functions as a time synchronization key.

Do you need to synchronize the involved computers at all?

I'm just a simple man with little knowledge on the inner workings of an electric brain, so I just wonder:rolleyes:.

[admiral 1]

As far as I can think it through, the only data that need to be syncronised during a race are the boat properties positions of the boats, speed vectors of the boats and a timestamp. When a race is joined environmental properties, the weather, see conditions etc should be transmitted in advance for the duration of the race. Environmental conditions and boat positions are then syncronized by timestamp. Lag then would only effect the boat of the lag suffering skipper and his screen ofcourse. The host would only have more traffic at the time joining. Obviously rulings will have to be transmitted also (if ruling is switched on) all else is handled locally. Lag is beaten (as in dead, forever done for, like none existing) when a server coordinates the data transmission, all timestamps transmitted at the same time, in revolving order. Race could be halted when timestamps are missing, not like it is now where boats seem to jump, slide sideways etc. This would happen with skipper with slow connections, therefore a connection speed limit should be implimented

[Bifrosty]

this is all being drafted up, for my multiplayer user interface that i'm gonna be sending to duran.

basically it will allow you to ping the host of the game, so you only join games with a ping time of 200. Also it will allow hosts to kick skippers from a game if they have high ping time...

this might not be to great for skippers with bad connections, but the ping doesn't rely that much on the speed of your connection, rather the quality...

speaking generally about lag, i agree with theo that sending a timestamp, along with a vector, and position is all the information that is needed...

A little intelligence in the network engine would be great too, so that boats that are close to each other is prioritized, meaning that more network packets are used on their vector and position than on other boats that are far from eachother...

all boats would need to sync in the start, downloading weather information, boat colors, skins etc. And most important of everything, getting the time right.

[essie]

hear hear on priorties!!! I hate that i get a lag pen from a boat jumping backwards and forwards at the marks, especially going to the winward offset mark!

[o2]

I totally agree with you Scott
But VSK is made like that we can t do anything to avoid lag pens.
, but it s always very frustrating

Moreover, we still enjoy to play, VSK isn t so bad for a first version of a game.
I think it s the best sailing simulation of the moment, which may be improved ........

So let's help Duran's team to give us a BETTER simulation for the second version of the game.

I won't be on VSK for a long time.
I am leaving to study in London for the next 5 months, and I am not sure to find a good pc and a good connection to have good races with you skippers.
So I ll have to study all the British beers for you. I will make reports on ITBYC forum on english :beer: testing.

So I hope to see most of you Saturday for my last races until July

[No Match]

I have one question about the present lag situation.
Do great disparity in the connection speeds between players increase the lag, so that if you have races where players are either uniformly slow or fast connected the lag will be less noticeable than otherwise?

[admiral 1]

A slow or unstable connection, will cause the user to miss updates on position and direction of the oposition. Likewise, the oposition will miss updates of the boat on that slow connection. The inoccent onlookers will notice an increase in uncertainty with growing numbers of boats involved, let alone a growing number of slow connections. Hence one boat with a slow conection can ruin your day....... 7 will sink you for sure.. :biggrin: This also goes fo playing on a WAN (that's what everybody in the VSK world is talking about when they mention LAN) connecting to a host through the internet. The best performance is on a lokal (the real LAN) network, ethernet and the like (less then 100 m apart).

Another cause for the current lag may be (guessing here) that the exchange of positions etc. is set at a certain minimal interval.
According to the system requirements for vsk a 28k modem can do the job........
On adsl and doing something in the 700k area there could be at least a tenfold in updates. (At frame rate ? when the amount of data is small enough...... :beer:)
The numbers for a lokal network usualy lie about an order of 100 (one hundred!) higher than your usual adsl. (yes that makes 1000 compared to the 28k modem!)
As there most likely is an interval implemented, the quality of the connection plays a major role. An analog modem might work better at 28k then 56k because of the quality of the connection (less data lost).

(Edited by admiral 1 at 12:17 am on Jan. 25, 2001)