[GAMEPLAY] toothtraps

[Craig_Perry 764]

Platform:

 

steam

 

rev number: 90423

 

issue; tooth traps don't always activate when an enemy goes over them.

 

steps to reproduce:

best way to see it is to watch a hound wave walk over a small area of traps

 

 

[Wade 301]

Okay, I'll have the team look into this for fixing in the future.

 

It's possible that some changes were made to the trigger range during the porting to the PS4.

[simplex 2,608]

Platform:

 

steam

 

rev number: 90423

 

issue; tooth traps don't always activate when an enemy goes over them.

 

steps to reproduce:

best way to see it is to watch a hound wave walk over a small area of traps

Yeah, that happens. The thing is the radius of effect of a tooth trap is 1.5 (wall sides) and it only checks for a nearby target every 1-2 seconds*.

* The actual value is randomized in this range per toothtrap each time they are armed (reloading a save counts as rearming)

EDIT: I just checked, and before the Maxwell update the target check was done every 0.4 seconds (with no randomization). If I were to venture a guess, I'd say the PS4 CPU wasn't handling tooth trap fields well so they increased the value.

[Silentdarkness1 1,160]

EDIT: I just checked, and before the Maxwell update the target check was done every 0.4 seconds (with no randomization). If I were to venture a guess, I'd say the PS4 CPU wasn't handling tooth trap fields well so they increased the value.

Wonderful, more screwing around done expressly to cater to the PS4.

[TeoSS69 2,204]

If I were to venture a guess, I'd say the PS4 CPU wasn't handling tooth trap fields well so they increased the value.

And to think my 5 year old laptop handles them

[JohnnyCash 1]

I, too, was wondering why they don't always go off when a mob goes over them. But I hadn't used them until some days ago, so I thought that was normal. 2 seconds can be a very long time in a fight.

[ChiefCommandeur 9]

Can confirm this issue. Very annoying since I then have to lead them around the traps for them to trigger.

[Craig_Perry 764]

 If I were to venture a guess, I'd say the PS4 CPU wasn't handling tooth trap fields well so they increased the value.

well that's a little irritating and kind of Ironic with all the "next gen" hype too

[Wade 301]

I can't see us decreasing the target check for the sake of PS4 technical ability, but it is more likely that something got changed when we implemented the capability to drop Tooth Traps and Bee Mines from the inventory without them being armed.

 

I've let the team know so they can look into it.

[simplex 2,608]

I can't see us decreasing the target check for the sake of PS4 technical ability, but it is more likely that something got changed when we implemented the capability to drop Tooth Traps and Bee Mines from the inventory without them being armed.

 

I've let the team know so they can look into it.

Only if that was an accidental tweak done in the process (in the sake of general optimisation, but forgetting to multiply by a factor), because the code changed is unrelated to that. The relevant code snippet is this (from components/mine.lua):

As it is now:

function Mine:StartTesting()    self:StopTesting()    self.testtask = self.inst:DoPeriodicTask(1 + math.random(), MineTest, math.random(.9, 1))end

As it was before (taken from Six Feet Under, but it had been like that for quite some time):

function Mine:StartTesting()    self:StopTesting()    self.testtask = self.inst:DoPeriodicTask(0.4, MineTest, 1)end

And there's a tiiiny bug in the "mine_test_fn" function used by the target seeking: due to a misplaced parenthesis, it's not really checking if the target can be attacked by the "mine". Though this doesn't seem to be causing effective issues.