Bug Report - Sync & Others

Hi.
After playing the nightly build and noticing similar issues in previous versions, I would like to report a few bugs.

Synchronization
Firstly there's a great issue with sync of players, when me and a friend are in a server with 50ms ping, we notice updates of our positions flawed and sometimes we twitch.

We spent at least a good 15 minutes roaming the wasteland, but something so minor came as such an inconvenience when we wanted to look at each other or watched ourselves twitch about the wasteland. It does work in some aspects, but the twitching can leave us wondering why someone is now behind us our not in an expected location.

Here's a video of a quick look at our game play, I also note that after a death animations break and I was unable to see my friend beat me to a pulp.

(may be currently uploading/rendering, give it 40 minutes ;))
https://www.youtube.com/watch?v=ygH71JubvOA

I can suggest movement prediction by sending a current movement vector and having the connected clients predict the position whilst it waits for the next x,y,z network packet. Another suggestion is making the difference between one point to another smooth, eg. drifting to the real location from its actual position. I can safely say that packet are not lost as the X,Y,Z positional data is combined into a single packet, so the room for error is massively reduced by two thirds.


Fighting
Sometimes when trying to fight another connected person, the person dealing the damage would crash after performing the strike. This was only happening to my friend, but stopped after we restarted the server and reconnected.

Interiors
Me and my friend were unable to enter interiors for fearing that we would lose visibility of each other. We would enter Vault 101 and only the first person to enter was able to see the other player, the person who entered last would be unable to see the player that was inside the interior. The problem then continued when exiting the interior to the wasteland and we would have to rejoin.

Thanks. I'm aware of the sync issues, and there has been a thread about it for some time, but I didn't work on it yet.

I will look into the other issues as well, thanks!

Quote:

---

Originally Posted by Silentfood

Another suggestion is making the difference between one point to another smooth, eg. drifting to the real location from its actual position.

---

I've actually been thinking about this for hours already in the past, and I'm looking to implement it, but implementation is a bit difficult, but I'll find a solution

Quote:

---

Originally Posted by Foxtacles

Thanks. I'm aware of the sync issues, and there has been a thread about it for some time, but I didn't work on it yet.

I will look into the other issues as well, thanks!



I've actually been thinking about this for hours already in the past, and I'm looking to implement it, but implementation is a bit difficult, but I'll find a solution

---

I've done this with other projects that use networking, and what I've usually done is kept the object holding it's own positional information. I can't explain it well in C++, but in Lua what I would do is:

Quote:

---

local player = {x=0.0,y=0.0} -- This is an array for the player, X and Y are zero.
local destination = {x=100.0,y=150.0}

function update() -- update is called on each cycle, so every update of the game's logic
player.x = (destination.y - player.x)/100 -- 100 being the drift factor, so after 100 cylces it would be at the location
player.y = (destination.y - player.y)/100
end

---

Hopefully that's understandable as I've never been good at documenting my own code.

Thanks, I know the concept, but the concrete implementation in case of vaultmp is not that trivial :)

EDIT:

I can't reproduce the interior issue you are speaking of, though I'm aware that it may happen sometimes. Is this bug persistent for you?

Quote:

---

Originally Posted by Foxtacles

Thanks, I know the concept, but the concrete implementation in case of vaultmp is not that trivial :)

EDIT:

I can't reproduce the interior issue you are speaking of, though I'm aware that it may happen sometimes. Is this bug persistent for you?

---

Yeah it has. Me and my friend (GrislyDragon) have had this issue every time, and even with another friend it also happens. It been happening with previous versions too. I know this has happened before when I ran a server on Tenpenny Tower and everyone exited the tower and no one was visible. That has the spawn cell set to the interior too.

My only assumption is when the interior is changed, because the Tenpenny tower was interior to exterior.

Some information about the server:
- Windows Server 2008 R2
- Default configuration
- Default ports
- Tried two different master servers (shouldn't be an issue)

So it does also happen if you i.e. spawn in the default spawn cell and enter Vault 101?

Correct, it also happens when we try a different spawn cell as described.

Did you try both the debug and no-debug versions?

Only the no debug, only realised there was a debug moments before writing the OP. I'll try the no debug in an hour or so.

I choose you Foxtacles! use witchcraft! now!

I couldn't replicate the issue when I was recording, but we managed to replicate another bug whilst playing.
https://www.youtube.com/watch?v=i859mxIb2-k

Thanks. It's clearly the bug you reported here:

https://www.vaultmp.com/showthread.ph...Radiation-Suit

I'll work on it next and update the nightly build when I believe I've fixed it.

I recommend using modified version of valve's approach to handle interpolation https://developer.valvesoftware.com/...yer_Networking

Quote:

---

Originally Posted by zamp

I recommend using modified version of valve's approach to handle interpolation https://developer.valvesoftware.com/...yer_Networking

---

Again as foxtacles said this isn't as easy to implement as one would think, I believe he said it was similar to working entirely backwards.