lordzelmer

Rookie
  • Content count

    10
  • Joined

  • Last visited

Community Reputation

2 Neutral

About lordzelmer

  • Rank
    Newbie
  1. Cancelling animation

    Yeah, that seems to be consistent with how I think it works. Due to miscommunication, your client thought the door were opened, but it didn't reach the server. I don't know if 'use' prompts are sent by the server or are wholly on the client side, but I think they are client-side, makes more sense. The immobility state seems to indicate that: player character is switching between states while playing, and if an action is executed (like opening doors), it would wait on the server response to stop opening and resume normal operation. If the server didn't get the action request, it couldn't send back the message to switch back to 'normal' state, thus making your character unusable. The funny part is, that reconnecting is the best thing to do - server needs to send ALL the data back to you about your player, so the states get reset and you can resume playing. This could be mitigated by checking periodically, but it makes for a really spaghettified code, less performance and bigger cost, and barring extreme circumstances, shouldn't be needed. Pretty much, yeah. I think door collisions are overall not very well polished, there are multiple doorways on Customs that you can't go through crouched at all. It seems more like a collision problem rather than networking. I think that, because player movement is (most likely) on the client side. Server just checks if it makes sense. So, if, for some reason, your client didn't load walls, you could walk through most of them without problem (that's how hacking works, by removing or changing things on the client side). If it was done in a 'safe' way, you would have a delay between your key press and your character moving (equal to your ping). Same would be for shooting, and believe me, it's horribly unresponsive to do it this way, even on low (<50ms) ping.
  2. Clipping into Corspes

    Ok, I've taken a harder look at the game and it seems that, in fact, EOT uses a very mild ragdoll physics for the dead bodies, so my whole post is mostly irrelevant. It's probably nearly impossible to sync dead bodies location without creating new problems and they will probably stay the same, but also most of the problems with collision stays, it's just worsened by the fact, that bodies can be in different locations for each player.
  3. Selling directly from equipment

    I agree, but this might make keeping bags in bags in bags in bags even more OP than it is now.
  4. Cancelling animation

    With the doors it might be a networking replication problem. I don't know for sure, but it's possible, that door states are stored on the server as a bool - opened, or closed. In short, they can't be 'partly opened'. This creates a problem: if you let players interrupt animations, they will quickly figure out where the 'trigger' is, as in 'how long do I need to wait before cancelling and still open the door?'. Since the door can only be 'opened' or 'closed' on the server, there will be a point at which the value changes. This would be greatly influenced by ping, too, so sometimes it won't be reliable, but for the most part you could figure it out in a way that makes everyone just skipping the animation. You could counteract that by only switching the value when the animation is complete, but that would result in a lot of bug reports of "I opened a door and it closed on me", or even worse: "I opened a door and can't go through!" if the server doesn't check the door state constantly (which you don't want to do for networking performance reasons). Edit: Clarification, in the second example (door opened, but you can't go through), your client thinks it opened the door, but the server didn't catch that due to desync, so on the server the door is closed, and since your client thinks the door is open, so you don't have the prompt to open them. You could probably fix this by 'closing' them and opening again, but that's not ideal.
  5. Deficit stock system for traders (Fence)

    If it worked like that, you'll get a cheating problem, you can't trust anything that's stored client-side. The resolution for that is keeping an instance of every opened inventory which might prove heavy on the servers, but those are only technical problems. Design implications are outlined by the post above, so I won't repeat that. And while I agree it would be a cool solution, it's not perfect and needs to be improved. I've wondered about this myself, since I suck and it took me 5 days to get 5 Salewa medkits, 4 of them bought from fence in multiple hours of clicking refresh
  6. Performance requires more love

    While the advice is on point, I feel like there's still time for optimization. I find it to be the last step in a game making for a reason. Still, those might be the things the devs just missed, so great job
  7. melee distance

    If flinching is a client-side effect, same as blood splatter and hit audio, this proves nothing. I've outlined how this (probably) works in this thread:
  8. Clipping into Corspes

    There's a question of if it can be done at all: 1. If the game uses ragdoll physics for dead bodies (which I don't think it does) Cannot be done, due to different locations of corpses on each game client. Since physics are calculated on the client, the body will be in slightly different place. 2. If the game doesn't use ragdolls (which is probably the case): It can be done, but it will create new problems. You'd need to make the dead bodies collide with players - this means you could stand on the body, it would block you from moving through it. But there's a problem: what if a body is in a doorway? If it keeps it's collision, you won't be able to go through. If it doesn't (like now), you will, but you can lie down in it. There's a lot more problems with keeping dead bodies collision - obscuring loot on the ground, blocking stairs or important locations, bodies piling up one on another (since you can't use ragdoll physics - they can't just fall off eachother) and so on - that's just from the top of my head.
  9. There must be something wrong with my guns.

    Yeah, you didn't but I was kinda explaining it for the hypothetical "Player B"
  10. There must be something wrong with my guns.

    I feel like I might shed some light on the matter. First, we need to explain how multiplayer shooters work. There's two components to the shooting and hitting, when it comes to this: What the player sees What the server sees For the game to feel responsive and snappy, developers have to do as much as they can on the client. This means things like blood splatter, muzzle blasts and so on - those are calculated from the point of view of the player. Unfortunately, the server can't believe what the client tells it. In games that take client data over their own, cheating is *extremely* easy and it leads to other problems - if you get a bit of lag and all other players stop moving for you, you kill them "your side" and server has to believe you. It doesn't take into account where the player really were - only where your client though they were. So, most developers believe what the server sees for calculating hits. There's a leeway built into this (most of the time), so if the data client sends is believable, some games take the client side (I think Overwatch and Battlefield do this, but I didn't check this, so don't quote me on that). Now, all this wouldn't be a problem, if players were synced. Problem occurs when there's a delay. Let's draw an example: Player A has 100ms ping to the server, player B has 250ms. Player A sees player B just going behind cover. Problem is, player's A view is 350ms behind. That's 1/3rd of a second, and from player's B point of view, he's well behind cover by this point. But from the server's POV he's somewhere in between. So player A shoots, hitting B in the head two times. He sees two blood splatters, and hears two hits. Server sees one hit, because second one was out of the leeway provided. Server sends a death message to player B, player B goes on the forums, because for him, he was headshotted by a cheater from behind cover (which is totally understandable if player B is not a network programmer or doesn't know how this works). So, we could just wait for confirmation on hits before showing effects like blood or hit audio, but that leads to very unresponsive game. You can feel your ping. Now for the second part of this, specifically related to the problem of "I die i one hit and they all die in 5". This comes down to the refresh rate that server is operating on, so called tickrate. From what I hear, some games run a very low tickrate (PUBG is about 10-15 ticks per second - again, don't quote me on that, not verified). With 15TPS that's about 60ms between checking the state of the game and deciding what happened. So, if two bullets hit between frames, only one update has the time to get out. If the tickrate slows for a bit (those are rarely stable), you might run into situation when 4 or 5 hits come in between ticks. This manifests in a simple way: you, as a player that got hit by those 5 shots, get only ONE update, with all of them at once, and it seems like you died in one shot. With effects (hit sounds and particles) executed on the client side (you seeng 5 shots hit), low tickrate makes for this exact situation. We know the servers are overloaded atm, this might mean they run at a lower tickrate, than they should. Game is also not optimized yet, at least not fully. So, to conclude. The situation you describe was in fact totally fair, but due to limits in light speed and processing power and how the network works, those situations are unavoidable. I hope this helps, let me know if I can expand or explain anything