Escaping with pig trap on?
I just played a match of survivor, vs a pig and at the end a bill had gotten a trap on his head and hooked. I unhooked him and it seemed like he was looking for somewhere to take his helmet off so I headed to the exit gate. We he came too and the pig was following and we both escaped. Like I thought he'd die, or did that get changed when they added a 5th box to take your helmet off?
Comments
-
As long as it's not active, you can safely leave through the gates with it on.
31 -
only activated bear trap will kill you at the gate. If it was put on him during end game, he was safe
11 -
The helmet has to be active for the trap to kill you at the exit gate - if the Pig puts the trap on a players head after all 5 generators have been completed, it won't activate, and thus the survivor can leave through the exit gate with it on.
4 -
People who escape with bear traps start the next match with it on, even if they are not vsing pig.
Imagine that lmao.
14 -
If there is not a red timer on the HUD for the helmet, it means it's not active. For the helmet to be activated, it has to be put on before a generator pops. Because if the Pig put the helmet after all the generators were done, the helmet will never be activated and the Survivor can escape through the gates.
But if it's activated and you don't have time to remove it, better hoping for your teammates to leave because the only way to escape is through the hatch then.
2 -
BHVR came to the decision to make the traps completely and utterly useless in the endgame, so as long as they aren't active people can just walk right out of the exit gate. Imagine that.
6 -
Nerf Pig.
(Before someone gets angry at me: it's a joke.)
2 -
NOOOOOOO
0 -
She's too OP! Top S++++ Killer!!
2 -
Swapped my picture to Pig just to protest your outrageousness
0 -
OK, OK, I'm doing the same to show how OP she is and how she needs to be nerfed to Oblivion!
1 -
Thanks everyone, I didn't know that about Amanda, it was during endgame that the helmet was put on. Much appreciated ❤
0 -
As a constant Pig player, I'm surprised at how many people I go against (or play with when I'm doing the solo survivor thing and we're facing a Pig) aren't aware of that. I've seen random survivor teammates frantically seaching for a box during EGC with inactive traps (and dying for it), and I've seen a survivor with an active trap not bother to take it off and run teabagging with their teammates into an open exit gate, only to die, lol.
2 -
Traps are meant to stall the game, not to get kills out of it reliably. If the gates are powered, stalling is no longer required. Also having to remove a trap when EGC is active is a near automatic death sentence. If that occasionally happens (killer closes hatch with the last surv. having an active trap), thats already pretty bad. But giving the killer the ability to enforce this situation on a survivor (placing a trap thats automatically active and then activating EGC by opening a gate) doesn't sound very healthy.
2 -
Yeah they did this when endgame collapse was added I guess they felt like it would have been overpowered with collapse?
1 -
I'm not upset at the fact that her traps got nerfed for endgame, they could have potentially become extremely oppressive and it was a good decision, I'm more-so upset that she got basically no compensation whatsoever and still remains a terrible M1 killer with two parts to her that are nearly unviable to use unless you have add-ons because of how bad they are (Stealth, Ambush).
1 -
I feel like they could have done something to make it work, or at least give good compensation buffs for removing her endgame pressure, neither of which happened.
0 -
"If the gates are powered, stalling is no longer required."
That is in no way true. Otherwise, we wouldn't have perks that slow down the process of opening the Exit Gates or actively stop Survivors from escaping.
As far as EGC, just pause the EGC timer as long as someone is wearing an active RBT.
4 -
One might even say... pigheadedness?
1 -
a lot of pig pfp in this post......
2 -
Active hat, hatch is your only escape
Inactive hat, the gate is how you're safe
0 -
Hee hee hee
0 -
Stalling as in bothering the survs with an additional objective that is to be done besides the main objective. Not to be confused with gen defense / gen regression perks, they just mkae it harder to finish the main objective. So pig traps are stallling, bc they force the survivors to get rid of their trap, which is time not spent on gens. During end game there are no gens to be done anymore. Only the gates, but they are finished fast, and progress cannot be reverted. So I would argue there's no real stalling in end game. Only some hindering factors (end game perks).
Since you meantioned end game perks: That ones would make auto-active traps in endgame even more disgusting, bc it would give the killer more time to down survivors and utilize the auto-active traps more vigorously.
0 -
I'm talking about Remember Me, No Way Out, and Bloodwarden.
Plus, all those issues you mentioned go away if you just pause the EGC timer when someone is wearing a Reverse Bear Trap.
1 -
I'm not a fan of pausing the EGC. It is meant to run out, thats its purpose. Let's keep that simple. As sad as it may be to the pigs end game potential, I think removing the auto-active ability in end game was the cleanest, easiest solution to do.
0 -
There will still be an end to the game because the RBTs will eventually either come off or kill the Survivors, which causes the EGC clock to start ticking again. The EGC will still be doing the job. The nerf that BHVR gave to the Pig for EGC was the WORST solution because it nerfed a weak Killer for absolutely zero compensation when there was a perfectly viable alternative that kept the best of both worlds.
2 -
It's still not a clean solution. "We will introduce this new mechanic called EGC, but for Pig we introduce this exception." That's no good design, it creates a dependancy between a killers power and a game mechanic, and every additional dependency makes the code more fragile and error prone. We always complain about the seemingly poor code quality of the game, but doing what you propose would actively reduce said code quality. That's what mean with clean solution: EGC behaves the same for all killers, there's no interaction with a killers power. We should always aim to decrease dependancys and harmonize mechanics. That's the reason why Tinkerer was reworked to its current version, btw, bc. the previous effect (increasing the effect of killer addons) was a nightmare to maintain.
Edit: About the "zero compensation", an effective Pig should and will use all her traps before EGC starts. So if anything, it's a nerf to Pig players struggling to get four downs before all gens get done. But luckily there's a solution for this: getting better / being more effective with Pig, as cliche as this may sound (the git-gud argument).
1 -
Really wish they'd revert that, poor Pig.
1 -
But but I like giving survivors party hats before they leave! Don't make me sad and make the party hats explode... :(
Shared this before but...
2 -
You can only be so good with a m1 killer vs any capable survivors, and in the current meta you can go for ages without getting a down because survivors just hold W if you try to ambush at pallets, and looping Pig is the same as any other m1 killer. You make a really good point here, and honestly this is why she needs a full on rework (imo). No other killer had to be tweaked on the endgame mechanic other than Pig to my current knowledge and that's just bad design.
The higher mmr you go the worse it gets too, as you have absolutely no lethality in chase, ambush is a joke at a majority of the pallets in the game, her add-ons are lackluster other than her purples and ultra rares, which are absurdly strong. Her power just needs a rework and she needs the focus taken off of RBTs and more needs to be incorporated into her base kit and just making her better to play.
0 -
I don't see why that's bad design. If anything, I would call that GOOD design because it solves the problem of the RBTs during the EGC in a way that allows both to still do their job. A bad solution to a problem is one that solves a self-made problem through unnecessary collateral damage while also NOT EVEN SOLVING THE PROBLEM ENTIRELY (because right now, you can STILL put Survivors in a position where they have to deal with an active Trap while the EGC timer is running). You talk about how the EGC should behave the same for all Killers, but the Pig was the ONLY Killer in the entire game (at the time, though even still now) who was actively made worse off as a result of the EGC.
"Git gud" is not a good answer to nerfing an aspect of a weak Killer that was not problematic until someone chose to introduce something that makes it problematic, no matter how you slice it.
1 -
Bringing more Spaghettis into the already large pile of spaghetti code does not make it any better. And adding a special rule for pig traps in EGC is exactly that. No auto-activation of traps in endgame does also solve the problem, it's just not the solution you like. That it's still possible to have active traps in end game is not an issue, btw, since they are independent from another code-vise. On the contrary, it would be bad to add some checks to actively disable them. Again, the goal should always be to REDUCE code dependencies.
About the "git-gud", we are talking about downing 4 ppl. Thats not a hell of task to do. And if you struggle hard to do that 4 downs, why should you be any more effective with auto-active traps in endgame? If the survivors are hard to catch when doing gens, they will also be hard to catch during end game.
0 -
Adding anything to the game is contributing to bad spaghetti code. You may as well say "adding the EGC is a bad design choice because it adds to the spaghetti code." If we're going to be adding something to the game, we're going to make sure that we're actually doing it well. Randomly screwing over one Killer while not fully dealing with the problem is the opposite of that. And no, if the problem they were trying to solve was "we don't want RBTs to be active during the EGC," then they did not actually solve the problem. Obviously, we don't want to be doing things overly inefficiently when it comes to programming, but that doesn't mean "don't make a minor tweak to for the sake of a small accomodation." Otherwise, we wouldn't have to, for example, have a list of things that AREN'T affected by Blindness. You claim that making that small change to the EGC is "adding more spaghetti." I see no reason to believe that it would result in coding problems beyond the worn-out non-argument "it's BHVR; expect the worst from them."
Like I said before, "git gud" is not an excuse for not taking the sensible route.
0 -
Any further discussion is futile. You show some great misunderstandings about code quality design, so let's just agree-to-disagree and move on.
0 -
I'm willing to learn if you can explain it to me instead of just alleging that I just don't get it. Simply going "don't make the spaghetti code worse" doesn't say anything. The EGC is already coded to conditionally modify the speed of the timer ticking down, so what exactly is the difficulty in adding another condition?
0 -
Don't you love when you invest time and effort and millions of blood points into a killer just to have it nerf to the ground down the road when that killer in not even S tier.
Post edited by Crimson_Lockhart on0 -
I already told you at least two times: Adding ANY conditional modification adds complexity, increases chances for bugs and unintended effects, potentielly makes the code a bigger mess and so decreases maintainability. Yes the timer slows down currently when a survivor is downed or hooked. But that works unconditionally for all killers, and is deemed neccessary to give the survivors enough time to rescue someone during end game.
Your proposal was to stop the timer when a trap is active. So you would have to change the timer to be stoppable, you would have to check whether a survivor has a trap on and whether it's active. And then stop the timer. It may not look like much code, but we don't know about the state of BHVRs codebase. So we have some additional implementations, which all can add bugs and glitches, and at least two additional conditions (trap on and active) we can be pretty sure about (there can be more hidden conditions we don't know). Furthermore we need to make the traps auto-active in endgame again, so thats some additional conditions for the traps (and likely some implementation). Since the EGC is relatively new, we can assume that it's still somewhat clean. The code for the pigs traps is older, and thus likely more messy. So getting it right might be more of a task, with higher odds of introducing bugs and other unintended effects.
All that effort for making the power of one killer work during end game / EGC (Freddy also loses part of his power in end game, btw). And also a change that might not even come into play (when all traps were already used), so it's conditiona whether the auto-active traps are even needed. That's no good code design for me, it adds complexity into the code base for just a minor benefit for one killer play. Code needs to be clean, easy to understand/maintain and modular. And your proposal is neither for me.
And one additional thought that crossed my mind while typing this: knowing about BHVRs difficulties with cheaters, I clearly can see such a stoppable timer as exploitable. All a cheater would have to do is sent the info to the server that the player has an active trap on, and the timer would likely stop. Even if there are no traps in play.
That are my thoughts about that. You can accept it or disregard it, do as you like.
0 -
No no keep going, play it through, you have to sell it to the OP, lol
0 -
That's just how coding works in general: The bigger and more complex the code is, the higher chance there is for bugs. That's game development in a nutshell, not a point against the idea. The fact that you understand that you don't know the game's code should be a crystal-clear cut that you (and I) are running purely off assumptions with this addition's impact to the game code. We're not actually arguing with anything but hypotheticals at this point, which accomplishes nothing. There's no reason to assume that this would be legitimately difficult to implement outside of "but maybe it'll break things".
The cheaters thing doesn't really say or mean anything. Why? Because "cheaters can maybe exploit it" can apply to just about anything about the game. A new Killer, a new map, a new anything. You're inventing a scenario in your head that we don't even know is possible to justify your position. By this logic, I could say that cheaters can just send info to the server that EGC never progresses period. Why should that matter?
Considering that you are accusing me of having gross misunderstandings of coding, everything regarding the "technical hurdles" of making this change that you put forth amounts to little more than guessing. It doesn't actually mean that the hurdles that you're hypothesizing actually exist in a meaningful way.
0 -
And there's also no reason to assume that it would be easy and NOT break anything!
About the cheaters, when you change the EGC to be stoppable by an active trap, how do you think the server will recognize that? Bc a clients sends the info. And that info can be forged / spoofed. How do you think all the other things that cheaters can manipulate are done? Exactly the same, they are sending forged / spoofed content to the server, which the server than accepts as true. Of course the server should not allow something like that, but we know it does, considering all the stupid cheats that occur. So I'm not talking about some vague risk here, but a very specific one! One we won't have when EGC cannot be stopped.
Technical hurdles is one thing, code design the other. If it's technically challenging we don't know, but adding an unneeded (imo) interaction between EGC and traps is also a flawed design (atleast for me), and that alone is enough reason to not do that.
0 -
If there's no reason to assume it will be difficult or easy to implement without breaking things, then this is not a point that can be argued in either direction. It's a non-argument.
You are inventing a worry that entirely theoretical. It is pointless to argue about it because there is no way to demonstrate it to be a legitimate concern.
Code design and technical hurdles are two sides of the same coin. I believe it is a needed and beneficial interaction that both solves the problem better than the current solution and does so with less collateral damage to balance.
0 -
Ok so we still disagree. Can we move on now?
0 -
If you want to move on, just stop responding. I still think your points don't really hold up at all.
0 -
Nice, then bb and see you later in another thread ;).
0 -
Did they change this recently? Or is there an add-on that makes it activate when all gens are done? Because I just watched a console player die at the exit gate with an inactive trap on their head.
0 -
Keep in mind that the timer will appear as inactive when they're being chased, even if it is in fact active. If that's not what happened, then I don't know.
0 -
When referring to traps it is true.
The trap cannot be activated after ecg has started. So your semantics are pointless.
0 -
I would LOVE if they add a addon that makes the jigsaw box activate after the gates are opened
0 -
I don't understand what you're saying. The person I was responding to was saying that stalling is pointless during the end game, and I was explaining how it wasn't. I know that Traps don't activate anymore at that point in the game, but that doesn't actually diminish the point I'm trying to make at all.
0 -
The person you quote in my original post was refering to its pointless to stall a game at ecg, he was refering to the use of traps after ecg.
So in game traps are used mainly to stall the game, not to give kills, however once ecg has become traps become no longer viable to stall the game. Which is what this thread is about traps and their uses etc, Not about some ecg build, but how traps work during ecg.
0
