The Division Trolls Are Blocking Other Players' Progress By Standing In A Doorway

The Division Trolls Are Blocking Other Players' Progress By Standing In A Doorway

Video: The Division has only been live for a day, but it's already got a hilarious griefing problem. As discovered by Eurogamer — and documented in their video, below — Division players with an inclination to troll can simply stand in the doorway of the game's opening safehouse. As you can see, this makes it tough to leave the room and start playing the game — even when the servers are working.

If you do run into a player doing jumping jacks in the doorway, one suggested solution is to keep running into him for a while until the physics finally relent and let you pass through. Or just have a safehouse party and never leave.


Comments

    as far as griefing goes, this is actually pretty funny.

      Unless of course you can't play the game you just paid for, because for some reason they feel the need to make people group up for that first zone. Nothing like being surrounded by a Bunch of Rando's getting in your way when all you want to do it talk to the first mission giver and shoot some stuff.

        patience. the first quest giver isn't going anywhere.

        but the image of some random, highly-trained spec-ops dude standing in a doorway, never breaking eye-contact, doing star jumps with a completely straight face is just too funny & absurd to get mad about.

          For the first couple minutes at best. At worst, they go AFK while their character remains in the doorway.

          Considering the installation, the Day 1 patch and you can't even do the first mission because this tiny apartment is a multiplayer hub, There's Patience and than there's this is a mostly single player Video Game I just want to play it.

    It's always unsettling when a huge game like this has this type of design flaw. It's not that it's a huge problem that's hard to fix it's that apparently nobody had the experience to say 'oh, make sure there's no way to block the doors, players love blocking access to stuff'.

    Last edited 09/03/16 3:04 pm

    from what people are saying if you run at the person you'll phase through after a couple of seconds.

      Should a lag occur and not detect collision?

      Yeah this is a pretty standard design decision flaw. Seen it in some other games as well.

        Collision is a continuous check, it'd just trigger as soon as your lag ended. If you were lagging enough for the collision detection to not work, you're lagging enough for everything else that requires server-side validation to not work either.

          If server has to validate the collision then any lag there could potentially cause the issue. It's a matter of timing.

            If you're lagging and can't get server validation that collision happened, you can't get validation of any other important event either - shooting, interacting with world objects, buying or selling items, even basic movement will usually rubber-band you back to where you were when the lag started in most games because the server validates movement to ensure you're not using speed hacks or moving illegally.

            Under those conditions nothing of importance works, collision detection is probably the least of your concerns. It's pretty standard design to work that way, there's only so many ways you can handle lag while ensuring people can't cheat. Prediction is common in MMOs but only goes so far in shooters.

            Last edited 09/03/16 3:33 pm

              Let me know when you've read the source. You worked on this project?

                Not this one, but other games, yes. Enough to know what passes for standard design and best practices with respect to multiplayer synchronisation and validation. The problem is managed in essentially the same way in all the current major licensed game engines; UE4, Unity, CryEngine. Would you like me to give you an end-to-end description of what happens on both client and server when a capturable event like collision happens?

                  In regards to another conversation we were having.I wouldn't really call it a conversation, but anyway, what is your take on speed runs that exploit design flaws? I don't know why I'm asking this. I guess I'm just curious.

                  Most game engines manage network synchronisation through a process called replication. Essentially objects in the engine that are configured for replication (actors usually support replication by default, but it can be added to any object) register with a replication handler that then manages the exchange of information. Properties of objects can also be replicated independently, as can events.

                  In network games there are a few kinds of replication. One kind is where the server instructs the client to create or change actors but doesn't otherwise care what happens to them. For example, you might have a particle effect when a switch is activated. The server doesn't care about it because it's just visual, it just instructs the client to make it and the client does it without any further communication with the server. Different clients may show the effect differently and that's okay because it's not critical data. If it were, it would use authoritative data (see below). Some clients won't have the effect shown at all because it's been deemed outside their relevance parameters, eg. if they're all the way on the other side of the map.

                  For important data, the server acts as the authoritative source. Movement in almost any multiplayer shooter is an example of important data. The client calculates movement based on user input, then every game tick it passes its position, acceleration and orientation to the replication handler, which passes it on to the server, usually with a timestamp attached. This data is sent essentially as a request, the client is asking permission for this change to occur. The server receives the data, processes it, determines if it's valid based on the rules of the game world (eg. can the player actually move this far in the time asked?) and then sends back a simple signal to authorise the request. Periodically the server will also send position updates back to the client to make sure there's no sync loss. Some games don't do this properly and you get desync, where on your screen you're fine but on the other clients you're running into a wall somewhere.

                  If the authoritative response from the server isn't received, the replication handler tries to requeue the request. If enough requests are sent through without a response, the engine senses communication loss with the server and attempts to re-establish that connection. In-game you may still be able to run around and interact with trivial things but anything that requires authorisation won't trigger. If communication is re-established, buffered requests are flushed through and the server will either catch up or send an authoritative position update, causing you to teleport back to the last position the server believes you should be. This is called rubber-banding, and you'll see it when lagging in almost any modern shooter today. If communication isn't re-established, you get disconnected. It's done this way because if the server just accepted any movement change the client sent, the client could just send bad data that warps the player all over the map instantly and the server would just dumbly nod along and say 'haha yep looks good'. That used to happen in some older shooters, and it's why all the modern ones treat movement as requiring authority.

                  I mentioned movement because movement is how collision detection works. Some collision can be done entirely client-side, like if you wanted the screen to tint yellow when you entered a certain part of the map or blue when you went underwater. The server doesn't care about that stuff. Other collisions are important, like when another player is blocking you from moving, so the server handles that entirely on its side by comparing your bounding box against the bounding box of the other object and deciding if they touch or overlap. In the case of the player blocking thing above, once the server detects an overlap it would start checking every game tick if that overlap is still there, and if it's there for 3 uninterrupted seconds it removes the physics interaction between the objects and allows the player to pass through.

                  The reason I said before that this kind of collision detection is continuous is because the client continuously sends movement data, and continuously resends it (some optimisation can happen here) when it doesn't get an authoritative response. If you lag, it will still catch up and know the collision happened eventually and for how long, so it's not possible to miss the start of a collision event due to lag, since it's continuous and not a one-off event. If you're lagging your client will certainly take longer than 3 seconds to let you through, but it won't end up the case that the lag goes away and you missed the event somehow.

                  It's worth noting that the above is standard practice for all the AAA game engines I've used. It's certainly in the realm of possibility that a new engine is written that doesn't do the above properly, but that's usually limited to engines that are personal projects or done from scratch by hobbyists rather than professional engines. It's possible The Division doesn't handle replication like the above, but I consider the chances to be very slim.

                  Hope that gives you an idea of how it works, I'm writing this while in a hurry to get out the door so I might have missed something. If you have any other questions let me know.

                  About your second question, I personally don't like glitch runs. It's fine that people compete on them, they just don't garner any respect from me, because to me using a glitch that clearly was unintended (eg. some of those Morrowind speed runs) isn't too far removed from using a trainer or entering a cheat code to teleport you to the end of the game. I have a lot more respect for normal runs that don't exploit glitches. But that's just personal preference, I don't judge other people for liking glitch runs.

                Sorry, I forgot to tag you in my reply above since I had to reply to myself and not you because of the comment depth limits. Just a heads up that I replied.

                  No, that's cool. I thought for a second that I would get some crappy try hard answer. That's actually pretty impressive. Just next time theres no reason to start a conversation by "You must be a real idiot if you think X". Just because some things don't come to mind or two people think or see things differently, I don't see the reason for such a comment. Leads to all sorts of negative things.

                  In regards to collisions and server side processing. In WoW, (I'm not saying all games are the same but probably used to follow similar process) my experience was that the object that attacked my character would go out of sync from time to time. Leading to the following:

                  I attack npc/whatever.
                  Combat state is changed to engage.
                  The npc stands there on my screen, while I move back and am getting hit.
                  I can't hit it due to it being out of range as I have moved away, but I'm still receiving damage. The npc hasn't moved on my screen.
                  So I move back to where it is on my screen and then I can hit it.
                  This is all attempts to attack were in line of site though range was very short. Sound effects would be handled on my end and each attack I can hear a strike. Perhaps the sound was attached to something other than animation. As there was no animation played on the attacking npc.

                  Perhaps wow did things differently, but I have experienced similar issues with other games.

                  Tera on the other hand had the collision douche exploiters too. Though they changed it to allow people through. It's a simple design flaw. What would people use to ruin the experience of others? I know I don't do sum a thing because it sucks, but we are playing on the internet.

                  Though collision can be an advantage/disadvantage in combat, in normal/neutral areas I don't see why it would need to be checked at all. Collisions should only be checked in areas where it matters. I don't know. That's just my opinion.

      Yeah, it literally takes like 3 seconds and it'll let you through...

    god damn trolls, i had to server hop like crazy to get around all these trolls.
    the line to the god damn computer was just as bad but once pas that initial mission its smooth sailing
    http://imgur.com/gallery/vylMR

      Or just run into them for 3 seconds and it disables the collision....

    Sometimes I wonder why we invented multi player games.

      Because fighting bad guys with your buddies is awesome, getting griefed by random jerks is not.

    It's still a dick move, but according to the devs, the fix is pretty simple.

    Instead of running at them and then backing off, continue running. After half a second or so you just phase through.

    What annoys me is when you free hostages an they stand in the door way

    It's worse when they stand in front of the laptop in the safe house and prevent you from activating. No physics bump to get you past then.

    Man game looks great but it blows by yourself tbh. Playing with my bro is fun but these human enemies are getting boring already, seriously just head shotting the shit out of everything and it's fucking easy. I guess the missions on hard would be better. I know it's a realistic theme...but I'm crying for some mutated virus carriers for some variety haha.
    Edit: just played a couple missions on hard and that's where the challenge is at for real...have to use tactics to actually win,so that's good. Enemies still getting a little stale already tho!

    Last edited 10/03/16 2:02 am

Join the discussion!

Trending Stories Right Now