Netcode

[Hylis]

Even if some players are saying "random", we are obviously not using a random function to determine outcome of event. It's more that there is less precision to see why things fall on one side or another (like the sides of a coin)
So, the goal here is to limit the perception of chaotic situation by display the best choice of information. As engineer, this is a part where we spend not much time at thinking, and I think we can improve by doing it.

For example, for the next update, we have now decided that laser has a priority over rockets when being fired. It was fair before, and it's still fair now, but it's more easy to accept now than before. It's just improved by the rules of display.

For capture of a pole or a door, maybe the rule should be to display 100% only when the message from the server is saying it. But it would make a 99% that would display for long time, not making this really nicer. Whatever we do, it's clear that two people in two different cities in Europe can not know instantly at how much is captured the pole at 15 ms (1500 ms of capture time / 100 scale of 100%) of precision at any given time.

Main reason: there is time taken for the information to travel

You can have 100 ms with this kind of numbers
15 ms from the input of a keyboard, to software process, and waiting for the next packet to leave (netrate)
40 ms ping (upload to server + download from server)
30 ms (server synchro, process, netrate)
15 ms (process at the right time on the client,rendering)

The synchro in between is required to solve the fact that information are going in both side, and if attacker is wishing to take the pole, the defense is also firing a rocket. If two players, in battle, are on the pole, the capture should not move: this equation is made on the server.

The good news is: we have improved this, thansk to netvision & some performance tweaks & display rules

I will avoid to make theorical assumption of any numerical performance increase, since it can not be computed without making tons of arbitral choice of parameters, but I have great hopes that the result will be clearly visible.

However, for taking the decision that a pole is captured, we will still have to wait for the server to acknowledge it from all source of information and then send the packet to all players. What will help here, is that this information will be closer to what you already have on the client, when it arrives. So, it should generate less surprises.

I hope it maksens

[novationx]

This post was very good Hylis.
I already knew a lot but its good to hear this kind of things again! I also love that it will be improved a little bit in the next update!
The priority of the laser is also a good thing.

About the capture... Before the last update we never saw 99% ( or waaaaay less than now )
I think it was because you displayed the information differently in-game.

Now : 1-100% ( you see every number 2 3 4 5 ... 98 99 100 )
Before the update : Only intervals where shown ( 11% 16% 21% ... )

Ofcourse this is not the (best) solution, but because players will see 99% less, when they saw 100% on their monitor, they will rage/complain less.
Maybe NADEO could make it like that again? I dunno

[Hylis]

Tx. It's really good to see that we are synchro on this thinking. I also have it in mind to have this 20% per 20% scale.

But it removes information to the player and fun. Because even if the information is not precise, having it is more precise than not having it.

So, maybe we should make a user interface with the progress bar in small (0%, 1%, ... 99%, 100%) and a big & wide black empty space for something called "Captude Confirmed" that lighten when it's decided by the server. It would be like having a pick lock progression bar, and a clear vision of the lock that is open or not in 2D.

[steeffeen]

For capture of a pole or a door, maybe the rule should be to display 100% only when the message from the server is saying it. But it would make a 99% that would display for long time, not making this really nicer.

i can confirm that
in my SpeedBall script the capture bar is accurate and waits on 99% even if the server says 100% but hasn't granted the capture yet, the interval between 100% and capture is basically only 10ms on the server but on the client it feels like 99% is displayed 10 times longer than any other percentage
so players sometimes think that the capture progress stops on 99 more often than on other values which is unpleasant as well

[pksens]

I wish it was always a matter of 10ms.
Example I posted recently: all according to a server replay so ignoring client delay/synchro:
1500ms to capture
20ms for 100% to convert to 'victory'
20ms (at least) slowed capture rate between 98% and 100%
I needed at least 1540 capture time to win.

The client replay processed the pole more accurately, giving me 100% in 1500ms and converting to victory in 10ms. Which again puts the 100% marker visible for 10ms longer than any other digit. Anyway I'll discuss your point Hylis:


If it's a matter of one of the card trick made more famous by David Blaine who asks the spectator to select a card from a deck that's being quickly flashed in front of him, but delaying 1 card by a fraction to make it selectable without the user knowing its intentional.. then:

.. perhaps you could put 150μs extra per 1% captured to total an extra 15ms by the time you hit 100%. The 15ms that should be enough time for it to accurately describe the win condition (assuming what I had on my server replay capture as an unfortunate event).

Although I do the extra on screen display recognising the capture. Data is good (display latency for everyone!).

p.s. are there some intentional variables: if you step on and off the pole it continues to capture at a slower rate. Step off, and its like 50% speed for 50ms, step on and its 75% speed for 50ms, or so. I'll have to look up one of the replays where we felt the attacker was sufficiently boosted away from the pole at >95% and see if it was indeed still capturing for 50ms to give him 100%. Probably intentional.

[Hylis]

I would also think that deciding of the capture is an additionnal 10 ms like steeffen says, but I do'nt think that you can require more time to capture. It's more that something happened while you were capturing and still not aware off. Because for this, it's more like the example I said about the 100ms.

Another example of things we changend in the netcode that may create different feelings is that the rocket now explodes on client side when it's on the set, and still no the server when it's on other players. At first it was all client, then we put all on server and now it's a mix. When it was all on client, you can have touched someone and no +1 linked with it, if the server decided that you did not touch the opponent. This is a simple case to understand on why there are choices to be made in order to only decrease the trouble, since it can not be entirely erased. This client side rocket explosion shall make for a better feeling in obstacle and in general. The 'bug' that players may see is that the rocket will explode on a set, but still hit someone as +1 (not yet informed) So, at the pole, you may think you hit the ground (for a bump) but in fact hit someone else instead. However, the two things we made, on performance & vision should help this as well.

And no, there is no smoothing of capture like you ask.

[TheBigG.]

It would be nice if Maniaplanet would also be IPV6 compatible because atm i don't have native IPv4 and my ping to ovh is via ipv6 50ms lower than via ipv4 because i don't have to use a tunnel broker. I know normaly Proivder doesn't have ipv6 but my provider is out of IPv4 and won't get IPv4 adresses from RIPE and in future. i think more providers will have this problem since the RIRs are out of IPV4 and Internet user count is still growing.