
ushas
Members-
Posts
200 -
Joined
-
Last visited
Everything posted by ushas
-
Yo ushas - I think I found why DR values are borked
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Ha you made a Crit hit to the rounding daemon mystery. So now, if I understand the armors with quality enchantments, it may work like this: 1. It looks like combat log and character screen info is getting the base item numbers and adds flat +2/4/6 bonus as stated in the corresponding enchantment desctiption. For base Hide, 125% of the base DR for Pierce and Freeze, and 50% of base in Corrode DR: Hide armor DR: 5.0 (Pierce 6.25, Freeze 6.25, Corrode 2.5) Fine Hide armor DR: 7.0 (Pierce 8.25, Freeze 8.25, Corrode 4.5) -> on char screen: ( 8, 8,5) Exceptional Hide armor DR: 9.0 (Pierce 10.25, Freeze 10.25, Corrode 6.5) -> on char screen: (10,10,7) Superb Hide armor DR:11.0 (Pierce 12.25, Freeze 12.25, Corrode 8.5) 2. However, the item description page estimation is diffrerent. Perhaps it adds +2 to the base DR, because those are always right. Then it percentualy estimates individual subtype DRs from the new quality base value:) For base Hide armor, 125% of the base DR for Pierce and Freeze, and 50% of base in Corrode DR: Hide armor DR: 5.0 (Pierce 6.25, Freeze 6.25, Corrode 2.5) Fine Hide armor DR: 7.0 (Pierce 8.75, Freeze 8.75, Corrode 3.5) -> in Item desc.: ( 9, 9,4) Exceptional Hide armor DR: 9.0 (Pierce 11.25, Freeze 11.25, Corrode 4.5) -> in Item desc.: (11,11,5) Superb Hide armor DR:11.0 (Pierce 13.75, Freeze 13.75, Corrode 5.5) Note, this can explain why there is different behavior for smaller DRs than the higher ones, and why is the difference in case of high base DR values even bigger... Also, nice to see another rounding level;) Well done, Sensuki! Now I fear what is intended behaviour... -
Ook then. So not to make this completely redundant, one more readibility issue with the numbers: [Problem] As the game is trying to conform to colorblind, I think developers might be also interested to make it accessible for people with low contrast sensitivity (especially in low light conditions). One of the troubled but easy to fix examples can be looting money items issue. See picture below The number of stacked coins is white-like and diplayed over light-colored coin pictures, which makes harder to decipher the amount. [Expected behaviour] Well have it easy to read. In the looting interface there is some dark cloud under numbers displayed over character portraits (to show number of remaining free slots in the inventory). So perhaps something like that would help in this instance too. Or even making borders around digits dark makes difference.
-
[435] Loot list / container issues
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Thanks for info. Ok, as they are still working on it, better to leave it for the next Beta, if needed? However, we can only try things a few times, no real statistical tests... -
Thanks for answers. It didn't show me your other post where you are providing the table, so my questions were off, sorry for that.
-
roguelike, that's really interesting. A few more stuff, I would be also interested to know, if you will consider Sensuki's request: -- How did you estimate Two-Handed, in comparison to others. -- How did you consider selection of armors. Assuming the armors you listed there: Plate A. DR: Slash: 15.0, Crush: 12.0, Pierce: 15.0 Mail A. DR: Slash: 13.5, Crush: 4.5, Pierce: 9.0 Scale A. DR: Slash: 8.8, Crush: 7.0, Pierce: 5.3 Lion DR: Slash: 4.0, Crush: 4.0, Pierce: 4.0 As Maces, Stilettos and Estocs have 3 DR bypass, one can simply add three points to their damage range, when considering opponents like these. Maces are Crushing weapons, making them even better against armors like Mail or Plate. But you know that. -- Why is there difference for Arquebus (6 DR bypass) between Scale Armor and Lion... -- What are Deflection and Accuracy values of targets and attackers, respectively. (Also what about hit/graze/crit) -- Whether the stilettos are faster than Maces and Sabres. Can I ask what in Interrupt mechanism is making one deal more damage?
-
[435] Loot list / container issues
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Just added a few you are not able to access to. Now I feel really dirty being aknowledged for savescumming:) -
[435] Loot list / container issues
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Yes I wonder about it too:) An exceptional weapon at lvl 4 can possibly make a big difference in the next fight... -
[435] Loot list / container issues
ushas replied to Sensuki's question in Backer Beta Bugs and Support
There are several other randomly generated containers in Skaen hideout, for example: Sarcophagus: 1. Exceptional Quarterstaff (810 cp) + 2 x Pearl (2 x 100 cp) + 333 cp 2. War Bow + Opal (150 cp) + 936 cp 3. 432 cp 4. Opal (150 cp) + 300 cp 5. 368 cp 6. PollAxe (10 cp) + 912 cp + Garnet (85 cp) 7. Exceptional War Bow (810 cp) + 575 cp + Opal (150 cp) 8. Pearl (100 cp) + 852 cp 9. 234 cp + 2 x Opal (2 x 150 cp) 10. 588 cp + Pearl (100 cp) I think the range is like ~ 400-1400 cp This had also a trap. I wonder whether the content changes when its triggered or disarmer (probably not). PS: Sorry for the smileys in the last post, I was confused that it didn't let me to put "8" next to ")" :/ -
[435] Loot list / container issues
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Three more containers from the central area of Skaen dungeon: Chest: 1) 288 cp 2) 870 cp 3) Pearl (100 cp) + 431 cp 4) 2 x Opal (2 x 150 cp) + 642 cp 5) Fine Sceptre (205 cp) + Garnet (85 cp) + 576 cp 6) 912 cp 7) 336 cp 8) 8. 2 x Opal (2 x 150 cp) + 450 cp 9) 2 x Garnet (2 x 85 cp) + 732 cp 10) Pearl (100 cp) + 402 cp Except occasional Fine Sceptre/Rod, or so, pretty much looted money and stones combinations in range ~ 300-1000 cp Barrel: 1) Scroll of restore moderate endurance (100 cp) + 465 cp 2) Exceptional Battle Axe (405cp) + 411 cp 3) 301 4) 546cp + Blunderbuss (200 cp) 5) Potion of major endurance (140cp) + 430cp 6) 729 cp 7) 720cp + Hunting Bow (10cp) 8) 8. Scroll of Missile Barrage (140cp) + 942cp 9) Crossbow (10cp) + 301cp (range ~ 300-1000 cp) A tombola container... Trapped Chest (always giving Rope and Grapling Hook (15cp)): 1) Granfathan Stalking Boots (110cp) 2) Granfathan Stalking Boots (110cp) + Potion of Major endurance (140cp) 3) Mantle of Wreathing Flame (110cp) 4) Cloak of Minor missiles (410cp) 5) Bracers of Deflection(210cp) 6) 2 x garnet (2x85cp) + Dyrwooden Charm belt (110 cp) 7) Granfathan Stalking Boots (110cp) 8) 8. Granfathan Stalking Boots (110cp) + Scroll of Prayer against Restraint (100cp) + 2 x Perl (2 x 100cp) 9) Girdle of Eotum Constitution (610 cp) (range ~ 125-600 cp) This isn't bad, as the container always gives you Rope and Grapling Hook and one special item to look forward to (boots, belt, cloak, gloves). Alhough, it can still minimize the other stuff. -
(BBv435, linux) [Problem] When browsing the stash container interface accessing it from inventory page, there is problem with readability of number of stacked items. The number itself is actually shown in the background under the item icon. See image below: When items are moved to character inventories, the number switches it's position to the foreground, and back to the background when moved back to the stash. The stash interface used in shops doesn't have this problem. [Expected behaviour] The number of stacked items to be displayed in the foreground above the item picture in all instances.
-
[Problem] A combination of enchantments and Might damage modifiers causes the character sheet to display much higher damage than stated in item description or the mouse over tooltip. Furthermore, even in case of modifiers from talents, the character sheet is showing higher damage than when estimated additively. For example, see: Damage modifiers applied here: 21 Might (+33%) Exceptional (x1.3) Damaging 1 (x1.15) Damaging 2 (x1.3) Two-handed style (x1.1) Adventurer specialization (x1.15) Savage Attack (x1.2) By additive rule the resulting damage should lie between: min: 14 * (1 + 0.33 + 0.3 + 0.15 + 0.3 + 0.1 + 0.15 + 0.2) = 35.42 max: 20 * (1 + 0.33 + 0.3 + 0.15 + 0.3 + 0.1 + 0.15 + 0.2) = 50.60 --> Much lower damage range than the listed one on Character sheet (55-78). A few notes: - So far, the issue is not detected when there is only one damage modifier applied to the weapon presented (eg. in case of Fine or Exceptional weapon and Might = 10). - I think the damage numbers on item description page take into account only item enchantments (quality) and Might modifier. - Damaging enchantments stack, so Damaging 1 + Damaging 2 -> +45%. I'm pointing this out just in case it's not intended behaviour. [Expected behaviour] To see the right actual numbers on character screen according to the additive rule, in compliance with other sources of damage information (item description, tooltips, combat log). [Discussion and more examples] In the past BB version, there was problem with multiplicative application of damage modifiers. According to the discussion with Sensuki, who was reporting and repeatedly checking the the multiplicative issue, and according to statements of Josh -- the assuption taken here is that the right damage values are those estimated by the additive rule. In this report I speculate, that the damage issue is perhaps still preserved for numbers shown on the character sheet -> thus the higher damage values for more than one damage modifier. Below, there are some more examples to back this up. 1) Quality Enchantments (Damaging 1 | Fine: x1.15, Damaging 2 | Exceptional: x1.3): Though the issue is already presented for Damaging 1 + Might modifier (the middle picture), the most obvious is the right one: Sword (base 11-16) + Might mod (+33% damage) + Damaging 1 (x1.15) + Damaging 2 (x1.3) Additive: min: 11 * (1 + 0.33 + 0.15 + 0.30) = 19.580 max: 16 * (1 + 0.33 + 0.15 + 0.30) = 28.480 Multiplicative: min: 11 * (1 * 1.33 * 1.15 * 1.30) = 21.872 max: 16 * (1 * 1.33 * 1.15 * 1.30) = 31.814 -> The character sheet numbers are closer to Multiplicative calculation (22-32). 2) Modal talents (Savage Attack x1.2, Reckless Assault x1.2) Dagger (base 8-12) + Might mod (+33%) + Exceptional (x1.3) + Savage Attack active (x1.2): Additive: min: 8 * (1 + 0.33 + 0.30 + 0.20) = 14.640 max: 12 * (1 + 0.33 + 0.30 + 0.20) = 21.960 Multiplicative: min: 8 * (1 * 1.33 * 1.30 * 1.20) = 16.598 max: 12 * (1 * 1.33 * 1.30 * 1.20) = 24.898 -> Again, the rounded character sheet damage (17-25) is too high for additive estimation. 3) Passive talents (Specializations: I think it's x1.15, Two-handed style x1.1) Compare to the left picture, the BB Fighter on right has Two-Handed style talent: Pike (base 14-20 Damage) + BB Fighter (Might 22 --> +36% damage) + Two-Handed Style Talent (x1.1 Damage) Additive: min: 14 * (1 + 0.36 + 0.1) = 20.440 max: 20 * (1 + 0.36 + 0.1) = 29.200 Multiplicative: min: 14 * (1 * 1.36 * 1.1) = 20.944 max: 20 * (1 * 1.36 * 1.1) = 29.920 On character screen it's listed: 21-30 Damage -> This doesn't fit additive calculation.
-
[435] Combat log event sort order appears to be backwards
ushas replied to Sensuki's question in Backer Beta Bugs and Support
There is also possible to come with order of events like this: So BB Priest and BB Fighter are beating the corpse and interrupting its fall;) My main character has exceptional estoc with damaging enchatments, high Might and specializations, as well as Savage Attack active -> high damage output. With this, it's easy to reproduce the above-like combat log entries on low Endurance targets like villagers or BB Wizard. Perhaps the order of events is right, the NPC death was too fast and party members still kept their momentum, still attacking (maybe made the attack resolution in the beginning of the action and the damage calculation later?). Regardless, I think there isn't much point to show the last three entries after the death of the target. -
[435] Background skill bonus inconsistencies
ushas replied to Sensuki's question in Backer Beta Bugs and Support
That's good point, Gromnir. Even partial shift of weight would make backgrounds more noticeable and especially skills stand more on their own next to classes. (eg. having just +1 bonus for one skill per class, if must) As now, it's partially class-tied. For example, why would one heavy invest into Mechanics on Fighter if there is Rogue in the party having implicit bonus +2? -
[435] Background skill bonus inconsistencies
ushas replied to Sensuki's question in Backer Beta Bugs and Support
That's interesting:) What about to combine this with classes, if I may join? Barbarian: +2 Athletics, +1 Survival Druid: +1 Lore, +2 Survival Chanter: +2 Lore, +1 Mechanics Cipher: +1 Stealth, +1 Mechanics, +1 Lore Fighter: +1 Athletics, +1 Lore, +1 Survival Monk: +1 Stealth, +1 Survival, +1 Athletics Paladin: +2 Athletics, +1 Lore Priest: +1 Athletics, +2 Lore Rogue: +2 Mechanics, +1 Stealth Ranger: +2 Survival, +1 Stealth Wizard: +2 Lore, +1 Mechanics On the left side there are numbers of classes giving +0,+1 and +2 bonuses, respectively, and the same for backgrounds, as provided by Sensuki. Additional fun starts on the right, where we combine them together for individual skills. Some highlights: - If I'm not mistaken, there are like 187 possible combinations. - It's actually quiet hard not to get any Lore bonus (24 cases). - In more then 100 cases (more then half) you will get at least +2 bonus to Lore skill. Please tell me I'm stupid here:)... - There are only two skills for which you can obtain +4 bonus: Survival (in case of Druid or Ranger + Colonist back.), and surprisingly Lore. - No love for Stealth (no +3 bonus). - +3 Mechanics only for Rogues, +3 Athletics for Paladins and Barbarians. Please player, take Lore skill, no pressure. -
[435] Sinful post-processing effects marring the 2D Backgrounds
ushas replied to Sensuki's question in Backer Beta Bugs and Support
Oh, you mean Sensuki was fatigued? That would actually make sense. Probably some biometric sensors connected to the game on higher tiers... Anyway, as this is not first person shooter (does anybody mistake it as such?), it would be desirable to make it at least as an optional switch in the menu, initially off. (as you already spent resources implementing it...) -
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)
-
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.
-
So I guess only villagers in clothing are "armor-less"
-
(BBv435, linux) In case it helps with something, I would like to add, that you can make held items reoccur again, when starting fight in the fog of war. The easiest way, how to reproduce this: 1) Prepare high INT wizard with the spell Rolling Flame; 2) Target the spell into an area with NPCs/enemies not in the visible range; 3) Observe that, after being hit, they initiate combat and now you can see things held by them in the fog of war. Picture below: Weapons and shields appear after being hit. And then you can watch the approach of enemies as items move.
-
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)
-
Another example is the pathfinding around units in a doorway. In left picture below, the party is ordered to go on the other side of the doorway, which should provide enough space. However they are not able to and are stuck behind NPCs in something like a queue. When I try to move a unit step by step, the passage is clearly possible. Through normally the selection circles act as solid walls, when you try shuffle enough, the game lets you to place the units so that the selection circles intersect, see the right side picture. When it's already possible, why not let the pathfinding AI use a slight circle intersection in tricky situations too? --> Change their borders from hard to soft limits...
-
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.
-
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.