[435] Trap issues

[ushas]

(BBv435, linux)

I will try to list all the issues with traps in this thread, as some of them may be possible related...

 

 

One trap per party member

 

[problem]
It seems there is some limit, like one trap per character, or so. When a party member plants the second trap, the first one disappears without triggering. There is no warning about it.

 

In most cases, traps remain when each of them is placed by a different character (sufficiently far away - see the next bug report).

 

 

[how to reproduce]
Place two traps by one party member.

 

 

[expected behaviour]
If the one active trap per character limit is truly intended, then the disappearing of the first trap needs to be dealt with or at least warned about. For example, automatically return the former trap back into the party's inventory.

Edited February 22, 2015 by ushas

[Sensuki]

It is intended.

[ushas]

One trap per area

 

[problem]

When two or more traps are planted (by different party members) to the same area or near to each other, only the last one remains (proceeds it's effects). So when disarming, only the lastly placed trap can be obtained back. Usually, the traps don't disappear if they are placed sufficiently far away from each other. (I don't know the exact distance)

 

 

[how to reproduce]

For example:
  1) Place two traps one over each other by two different party members.
  2) Wait for enemy to trigger them.
  3) See in the combat log, that only the lastly applied one is triggered.

 

[expected behaviour]

I would expect that multiple traps can be accumulated in the same area or at least placed near each other and properly triggered (or disarmed without the trap item lost). <- Assuming the game doesn't try to enforce some artificial limit here too (are the corresponding abilities limited one per area as well?), otherwise the trap disappearing should be dealt the same way as in the bug report above.

 

 

[comment]
Probably related to the one trap per character issue.

[ushas]

It is intended.

 

Thanks for info. Just I'm not sure, is the loosing trap item itself intended too?

[ushas]

Traps don't persist after reload (not sure if able to reproduce it again)

 

[problem]

In some cases the previously placed traps disappear after reload.

 

 

[how to reproduce]

I'm not able to reproduce it most of the time

1) Plant a trap by any party member
2) Quick-save the game.
3) Quick-reload, a try to find the trap again.

 

 

 

[expected behaviour]

The trap should persist.

 

 

[comments]

Probably one of the save issues? Also all of my reports are from the linux version of the game.

Edited February 22, 2015 by ushas

[ushas]

Unknown AoE radius of traps

 

[problem]

In the item description and during the placing trap action I don't see any indication of the trap AoE range (for all the traps I think). The description only lists the hazard AoE 1 m, which is probably an area for the trigger?

 

 

 

[how to reproduce]

For example, use the Tanglefoot trap.

 

 

[expected behaviour]

 

The modified durations of trap effects are listed in the descriptions and probably influenced by INT. So I would expect that the AoE range of the trap would share the same mechanism. It's possible that only the description page needs an update.

 

 

[suggestions]
During the trap placement, It would be useful to see the AoE circle/shape which will be used after the trap triggering, as well. (eg. as in case of abilities).

[ushas]

Interrupt on non-damaging traps (and related spells)

 

 

[problem]
Traps which don't do any damage trigger interrupts. This may be connected with the corresponding spells, in case the traps share the same code.

 

Tanglefoot Trap (and spell)

 

 

 

Gaze of the Adragan trap (and spell)

 

 

[expected behaviour]

In case I'm not mistaken about the mechanism connected to damage, these two traps should not trigger interrupts.

 

 

[comments]

There is even the Interrupt value on the description page of related spells.

 

Probably related to

http://forums.obsidian.net/topic/69265-333-interrupts-occur-on-non-damaging-attacks/?hl=interrupts

http://forums.obsidian.net/topic/70448-435-interrupts-occuring-on-lion-frightening-roar/

 

Also in case of the damaging traps, there is missing info about Interrupt numbers in the description.

[ushas]

Graphical glitches: Unbalanced elevation of the green trap triggering area

 

[problem]
The green area indicator shows inconsistent behaviour of its height above the ground placement, when compare to the the party members'  and other NPCs models.

 

 

 

[expected behaviour]
For better lucidity, I would expect the same elevation across the green area, no matter which character passes it. Preferably, have it on the ground.

 

 

[comments]
When placing trap for the enemy crossing, it's usually under his legs. I think the most problems show party members and friendly NPCs.

[ushas]

No Burn damage numbers in the description of Sunlance trap and spell

 

[problem]
In the Trap item (and spell) description, there is listed only Pierce damage vs. Deflection. But according to the combat log (and lore text), the trap (and spell) is inflicting burn damage as well. See picture below.

 

 

 

[how to reproduce]
Use the trap (spell) on enemies and compare the item description with the combat log damage.

 

 

[expected behaviour]
The burn damage part should be specified on the description page, for both the trap and the spell.

[ushas]

No effects of the Boiling Spray Trap

 

[problem]
According to the description, the Boiling Spray trap should inflict the burn damage and 2m push (cone?). But on Hit or even when Crit is done, there is no damage listed in the combat log. The game plays a special cone effect after the trigger, but that seems doing nothing too.

 

Also the item description says: "Hazard AoE: -2--3 Burn"

(12-13 Burn ?), see picture below.

 

 

 

[expected behaviour]
Trap should inflict the proper Burn damage and proceed the Push part when hits target.

Edited February 22, 2015 by ushas

[ushas]

Phantom raw damage of Poisonous Cloud Trap

 

[problem]
The trap description states extraordinarily high Raw damage (~>800) additionally to the Corrode one. When triggering in combat, the overall info in combat log lists only the Corrode damage dealt, but in mouse-over formula we can see the Raw damage too. Although, I think it isn't applied in reality.

 

The corresponding spell Death ring (lvl6) shares the same issue in the description, but the Raw damage isn't done nor listed in the combat log formula.

 

 

[expected behaviour]
The description page of trap/spell should show the correct damage. Probably the Raw damage part shouldn't be there at all.

 

 

[comment]
The name of the trap is Poisonous cloud trap, but the spell is Death ring (not sure if problem).

 

On a side note: The right combat log also probable shows the wrong order of events, as reported by Sensuki

http://forums.obsidian.net/topic/70526-435-combat-log-event-sort-order-appears-to-be-backwards/?hl=%2Bcombat+%2Blog

 

Here, it should inform about the damage dealt first and list the deaths of villagers afterwards, not the other way around.

Edited February 22, 2015 by ushas

[ushas]

Malignant Cloud Trap AoE just as a violet effect decoration for the time of duration?

 

[problem]
Besides not informing about the AoE range, as covered for all traps in one of the reports above, this trap's description also doesn't indicate the time of duration, in comparison to the source spell.

 

Furthermore, I'm not aware, that it truly does damage over time (as the original spell I think) past the initial damage. Even when the special effect carpet stays on the ground for some time.

 

 

 

[expected behaviour]
Of course, it's possible, that the trap isn't intended to do the same thing as the spell ability. However, according to the special effect longevity, I assume, that the Raw damage over time in the AoE is the intended behavior. And  the description itself should correspond that too.

Edited February 22, 2015 by ushas

[Sensuki]

Thought I might join in

 

 

Traps hit at a fair delay after units walk over them. In the Infinity Engine games they basically hit one frame after the unit walks over the trap ... here it's like 500msec or something like that. They should hit instantly IMO.

 

 

Can't stack traps you pick up with traps you haven't yet placed

 

Expected Result: both trap types should stack

Edited February 22, 2015 by Sensuki

[ushas]

Thought I might join in

Definitely. Thanks a lot for the videos, it's much better than I would be able to describe it.

 

Also possible related to the delayed hit?

1) The green trigger trap area stays on screen several seconds longer after already triggered delayed effect, then it should. (I think it's issue for all the AoE traps too)

 

2) When the trap is placed directly under the feet of friendly target, he doesn't trigger it when the combat starts. That's easy to reproduce with archers. But I think even the melee NPC when moving out from the trap area doesn't trigger it, only when passing through.

 

Interesting thing is that this works for me differently with befriended Skaen cultists (originally hostile), even their archers trigger the underneath traps. But I'm not sure about all of this.

 

[ushas]

Related to the non-stackable picked-up traps video, there the leader feature:

When a trap is disarmed it goes to the inventory of the main character, not the party member who performs the disarming...

 

 

This was already mentioned by Bazy, in the report:

http://forums.obsidian.net/topic/70285-435-disarming-of-friendly-traps-when-melee-attacking/?p=1572425

 

He talks there also about the more problematic issue:

When targeting (attacking) the NPC above trap at close range, the character decides to first disarm trap, and then perform the ordered hostile action.
 

So I guess it fits to link it here too.

 

 

Note:

I think one possible way how to stack them afterwards is to put the rest of the traps into the main character inventory and then pick the planted trap up by anybody.

Edited February 22, 2015 by ushas

[ushas]

Traps hit at a fair delay after units walk over them.

 

I think you found out why I had so easy time in Skaen hideout.

 

 

Pressure traps in rooms of Skaen dungeon are easy to pass through without any damage

 

[problem]

The image below tries to show that you can run through trapped room in the Skaen hideout: Triggered traps by passing through in the fast Double speed mode. And probably thanks to the delayed trap reaction, no damage taken.

 

 

Also I think the delayed hit doesn't change properly across all speeds. Meaning: you can easily run over traps in Double Speed mode, but have a harder time in Half Speed or Scouting.

 

 

[expected behaviour]

What Sensuki already said.

+

I would expect all the happening events to be adjusted accordingly to the chosen speed mode.

Edited February 22, 2015 by ushas

[ushas]

Problematic lightning targeting in the Skaen trap chamber

 

[problem]
The same room in Skaen dungeon as above. The room contains two sources of the lightning + 3 traps. The second and third trap from the left side control the same source.

 

Pictures below show the trajectory of lightning for the second or third trap, respectively - in comparison to the first left-most one. Their different targeting makes them easier to pass through.

 

Note, that the second trap's lightning completely changes it's path on the fly. I don't know why. That  means even longer trajectory, and thus more time for the party to pass unharmed;) (assuming constant speed) 

 

 

 

[expected behaviour]
Seeing that the party can approach the trapped chamber from both ends, I guess, the most certain is to target the trigger area itself as fast as possible. Eg. as in case of the first trap. And across all traps make them hit the target faster overall, as already proposed. (Here it would also help to have another lightning source in the middle of the room)

Edited February 22, 2015 by ushas

[ushas]

High Accuracy traps planted by party members
I'm not sure whether this is an issue. But it can be seen as such at least from the point of possible player's confusion.

 

[problem]
Traps placed by party members seem to have quiet high Accuracy compare to weapon styles/abilities at the same level, even in the case of the characters with Mechanics = 0, and compare to the accuracy of traps in the Skaen dungeon.

 

[further discussion]
The game doesn't clearly states how the Accuracy for traps is calculated. So the formula below is
estimated approx empirically by doing several tests:

 

trap_accuracy = [(class_base) + 3*(LVL-1)] + [21 + 1*(LVL) + 3*(Mechanics)]

 

Notes:
-- Left part is basically the actual base accuracy of the character.
-- The further increase 1 point per LVL on the right is the same increase as in case of spells.
-- The trap accuracy is boosted by magical constant +21 for all characters and levels.
-- On the description page of traps we can see -10 accuracy modifier --> so the magical constant can be +31, actually.
-- Each point in Mechanics skill provide +3 Accuracy for placed traps.

 

Picture below: Three rogues at LVL 4 (base Accuracy 39) with Mechanics skill 0,3 and 8, respectively, which correspond to trap Accuracy 64, 73 and finaly 88. (Sunlance Trap)

 

Compare to possibilities for weapons -- boosts from enchantements, abilities and talents at that level -- the listed trap numbers seem to be quiet high. Wizard spells at  LVL 4 provide Accuracy 43. Also the same trap which is used as an example here (Sunlance) was hitting party members with Accuracy ~50 when encountered in Skaen dungeon.

 

 

[expected behaviour]
I don't know what is intended outcome. However, some sense of consistency is telling me that the Accuracy for traps should be lower. Especially at 0 Mechanics. So the per point buy of Mechanics skill would look more useful. Perhaps abandon the flat magical +21 boost? (but I'm not sure where it's coming from)

 

Other then that, expected would be also to provide sufficient information about how traps work and what influences them (not only Accuracy info).

 

 

 

[suggestions and feedback]
According to BMac, there is a consideration to show effective values of accuracies in the tooltips of abilities:
http://forums.obsidian.net/topic/70577-meleeranged-accurcay/?p=1572086

 

Just in case it's not already resolved, I would like to pinpoint several places where BBv435 lacks in communication about real used Accuracy (not only traps):

 

1) As the abilities use different rules, the clear distinction is desirable. For example: If majority of spells/traps use also 1/lvl boost to accuracy and are independent of weapons, that should be communicated beforehand. Though, the effective values in tooltips provide solution, it would be good to pair it with easy accessible info where the numbers are coming from.

I don't know -- maybe make accuracy categories with proper explanation?...

 

2) As far as I know the class specific base numbers are listed on character creation. It would be useful have it in game accessible too (clickable class description on character sheet?).

 

3) As for the traps' accuracy, I think, there is no info at all, except the vague statement on the Mechanics skill page. So perhaps: expand the Mechanics skill description to contain all the needed info for full accuracy estimation?

 

4) Also all of this can be reflected in Cyclopedia page. There is no reason why numbers cannot be there, as others pages (eg. Afflictions) already contain numerical information.

 

5) If tooltips/descriptions of abilities are going to display effective accuracies, the same should stand for descriptions of traps and scrolls.

 

6) As discussed by others, it would be useful to show tooltip formula of actual weapon accuracy on character screen, so one can check the base and modifiers. As it is now: the long tooltip description will be useful to players several times, then start to be annoying (better to put it into the clickable description window?). On the other hand, the tooltip formula can be useful during whole playthrough.

Edited February 24, 2015 by ushas

[ushas]

How to change color of trap indication area

 

[problem]
The color of trap indication area is subject of change, in case it's planted by a friendly party member having active one of the modals, listed below. The original green is changed into red, while the trap retain the same behaviour.

 

So far discovered talents/abilities, which do this:

Savage Attack
Vulnerable Attack
Penetrating Shot.

 

 

 

 

[expected behaviour]
I guess traps placed by a friendly unit should have the same color, regardless of situation.

 

 

[notes]
Also detected in colorblind mode ( blue-> red)

Edited February 25, 2015 by ushas