ushas

Just in case not already considered: to my knowledge, this level-up AOE description error happens probably to all classes (with INT != 10), which are choosing their abilities. In attachment, there are examples of level-up and in game descriptions for abilities of Chanter, Paladin and Cipher. Also, when in character creation, the game doesn't take into account attributes at all, even when you choose a Godlike character. But that's probably a feature...

Yes, Alt would be perfect! Ctrl is a multiselect (thanks for that).

Or this is another option. As in the game now, it's half working. I would prefer a key shortcut, or is there any already?

(BBv435 linux) Swap items in full directory: [problem] Normally, when transferring items, you can exchange position between two things inside one or across different personal inventories, across inventory containers in general. This stops working when you want to swap an item from the outside (coming from different inventory, stash, or from equipped/quick item slots) for the item inside the full character's inventory. The exchange within the full inventory works as intended (because first you have to free a slot?). The same problem has the Quick items container. You can swap consumables, scrolls, etc., as much as you like, till all the slots are taken. Which has been already known: https://forums.obsidian.net/topic/70416-435-quick-item-slots/?hl=items [expected behaviour] The active item exchange should work consistently across UI, regardless the fullness of the container. Double click behaviour (recommendations): [unequip] When unequiping by a double click, while having full inventory, the behaviour is different, and the item remains in the equipped slot, in the end. The inconsistency of the double click behaviour overall may confuse the player. It would be helpful, if this is solved, as well. For example, you can let an unequip event to happen. But let the item remain to be picked up, as in case of the one mouse click, so the player can choose, where to put it. (he intended to put it out of the equipment slot after all) [equip weapons and shields] You can equip items (including rings) and put consumables into the quick item container by a double click. This doesn't work for weapons and shields, even when I have a weapon set slot free. It would be helpful, if you can implement equipping/switching by double click for weapons/shields too. Perhaps, it can be tricky with many weapon set slots. But you can set up an implicit behaviour, and the player then adjusts to his liking. For example, make it as in case of consumables and rings -> gradually filling the slots. [swap the first position in case of full container] Also, when quick items and ring slots are full, the double click equipping stops working for them, as well. Of course, it would have to swap the desired item with an already equipped one. (and which slot then?). But still, even if you make the double click swap work only for the first slot (aka as with armors), it would be useful. For example, when you want to use something fast, without too much mouse travelling, and don't care to which slot the thing goes... (consumables/rings/weapons) Edit to clarify: You can actually already swap rings in the first slot position by double clicking, but only if the character's inventory isn't full. That doesn't work for quick items, though.

I have looted a spell scroll (forgot the name), which lets you cast a spell outside the combat giving +3 to Athletics for ~100 sec. The description was ok, but after the casting from the quick items menu the character screen effect description and the combat log info states: *Missing abilities 1839*

Also happens when taking a screenshot (using Print Screen button).

Didn't you take this numbers from character creation screen? Or do you have some future info? I think, in the beginning of beta there was a report (and recognition?) of inconsistent descriptions: Char. creation lists that Int gives +1 Will per point above 10, but in game on char sheet you can see +2 Will, consistently with other attributes. After targeting Will defence of BB Priest, I tough that it's obvious that +2 Will modifier is the correct one in BBv435... But now, this discussion is so confusing, shorting my circuits.

Nice, that's basically what happened to me too. Thanks for the video. Wait, are we playing an RPG billiard?... Also I probably worded my post wrong. If all the pathfinding would be (almost) perfect, and a unit would always decide to go left, but only in case, when both paths are equal (eg. as an implicit decision for undecidable situations), will you consider that as a problem? I mean what one may observe as the left-path-choosing issue may be just situations, when a unit should clearly move to the other side than it did, as you demonstrated. My only concern is, whether we should see that as a root cause of the pathfinding issues (eg. a mismatch of left/right in the code, or decision to go left too early before pathfinding estimation, etc.) -> then changing it may solve a lot. Or should see it as one of the consequences of deeper problems (eg. a wrong pathfinding (re)calculation, etc.) -> then changing left to right, or a random combination, may not solve anything, as statistically speaking you will probably detect the same issues... (Please don't take examples seriously, I don't know anything about pathfinding.)

Indeed. That would be very helpful. Especially for food/drinks consumables. Players will probably want to fill quick items slots by short-term combat usable stuff. So eating from inventory can help minimize the management.

That's interesting. Thanks for videos. However, are you sure it's always (or only) a left-side preference, what causes problems in the presented situations? For example, if I move a blockade (from the second video) to block the right side next to hearthstone, the BB unit acts the same way. This time deciding to go right, hit the blockade and be stuck there. He will not go left around the hearthstone at all (till stationed at least half way there or so). Eg. see BB fighter in the picture I hope this helps somehow. Other than that, is it possible, that this issue is somehow connected to the pathfinding issue of narrow passages? http://forums.obsidian.net/topic/69757-392-pathfinding-issue-with-tight-spaces-between-other-units-unit-cannot-find-shortest-path/ For example, If there is some collision detection or obscure vision problems, those may affect both issues. As the left-path-choosing as well as narrow passage issues happen when the moving unit has to go near an obstacle...

Adding an example of this issue, this time with a narrow spaces between units/npcs and other things (a wall/table etc.). BB fighter is ordered to go left (the first panel). He actually turns left, as if going there, but afterwards he decides to turn and go around two units (the right panel). The same happens on the way back, when he is ordered to return to the original position. And there is no obstacle on the shortest path. I can walk him there manually. It's easy to reproduce by walking between lord Harond and the table in the inn, as well.

Also the same with the Deflection modifier, I guess? num += (int) (this.StatBonusDeflection + 0.5f);

In case of windows version, isn't the path like here? http://forums.obsidian.net/topic/67421-how-to-save-output-logtxt-and-find-saved-games/?p=1512371 on linux: /home/USER/PillarsOfEternity/SavedGames

Ha, so your effort has actually bad impact on game;) But now truly, well done! You are right these are whole numbers anyway... I think in C this would mean they didn't take into account negative numbers? (so it wouldn't work even in that original calculation): int(+3+0.5) -> 3 int(-3+0.5) -> -2 So it doesn't show any problems for positive sums of modifiers from attributes, but for the negative ones yes... But I'm never sure about this things. This is C#?

Oh no, I'm being haunted by rounding demon... Thanks, Sensuki, much appreciated if you can catch it.

Unfortunately, game forces you to use the found key. Yeah slightly unbalanced options;). But I guess you can power-game quests too... What I like about this doors you are talking about:

For Reflex, Fortitude and Will, there is +2 / -2 modifier to the corresponding defence per point of attribute above / below 10. And at lvl 1 the character will have the base 20 For / Ref / Will, without taking into account modifiers, if I recall correctly. So if you look at the first sheet, there is already written +0 For from Mig = 10 and -2 For from Con = 9, then it should be For = 20 + 0 - 2 = 18. Of course, the description and my estimation may be wrong. But your calculation would not work for the last character at all. As he has negative defences;)

The BB fighter has average Dexterity and Perception, both 10. When he suffers a reduction of any of this two, the resulting value of the Reflex defence is by 1 point higher than it should be. I did some tests with different builds and spells -- and it looks like this issue holds for all the defences modified by the low sum of connected attributes. The picture below shows different characters suffering by the bug: For example, the first character has: Deflection 25, Fortitude 19, Reflex 19, Will 19 -> Should have: Deflection 24, Fortitude 18, Reflex 18, Will 18 and so on with others... How to reproduce: A) either, by putting Hobbled or similar effect on BB fighter -- the reflex defence will be off; B) or create a new character from any of those in the picture above or similar (sum of two attributes modifying the tested defence to be < 20); [comments] According to several tests with different setups, the bug seems to occur only when the summed modifier from attributes is negative regardless to its value. It's like the game does something like this for Deflection: modifier = (Per - 10) + (Res - 10) if (modifier < 0) --> deflection = deflection + modifier +1 else --> deflection = deflection + modifier And for Reflex defence (and similarly for For. and Will): modifier = (Per - 10)*2 + (Dex - 10)*2 if (modifier < 0) --> reflex = reflex + modifier +1 else --> reflex = reflex + modifier Did some basic tests with attacking the corresponding defence and it seems the numbers are the same (wrong) in the combat log. Leveling up also doesn't help with the issue. Note: The first two character sheets also show the bug with bigger fonts (130%). The longer Background descriptions don't fit the sheet size.

http://forums.obsidian.net/topic/70277-435-clothing-texturemodel-glitches/?p=1565547

I don't know. Maybe because you can willingly influence your metabolism? Why would it make abilities last longer...

I think in game after consummation, the time shown when hovering next to the character portrait (and in the character screen info too) is taking into consideration only Survival skill, so it's something like this 300 * [1 + 0.45] = 435 seconds The same for potions. If it should work additive with Intellect (which would be great), the bug is probably in both places - in the description and in the duration itself, as well. Also, some of the potions don't show altered time for the character in the description at all (just the base time).

(BBv435 linux) [Description] There is an issue with text adjustment to the box in the the loading screen. When the loading starts, it looks like this: And after a few seconds it adjusts to the right formatting: [How to reproduce] The issue doesn't occur often. The highest probability for me to make it happen: 1) Change a font size to the higher (eg. 130%); 2) Start a new game; 3a) Observe it on the loading screen after the character creation; 3b) If not happened return to the point 2) and try again. [Comments] It looks like there is a change of alignment from center (doesn't fit the box) to justified... Probably connected to the font resize problems?

In Winfrith's arms and armory, a rapier: *Missing items 1881* (name) *Missing items 1882* (description) *Missing itemmods 246*

Thanks cRichards. It can sound as an overreaction:). A lot of players, including me, will probably not detect nor analyze small differences like the combat formula stuff and health/endurance, etc. But the point is to highlight overall picture build up from details -- When you have several inconsistent behaviours or even accumulate negligible operations one over each other...

(BBv435 linux) 4) Sometimes, the combat log formula shows wrong calculation of the difference between weapon damage and the corresponding DR: [Description] When checking the combat log tooltip formula for damage calculations, some of the results don't seem to look right. And the difference is often 0.1. For example like this: 24.6 - DR:6.3 = 18.4 Pierce [Expected behaviour] When you are going to show formulae with solutions, good manners are to have left and right sides equal (L=P). Otherwise it can look slightly unprofessional?... [Comments and speculations] Having an idea where it's coming from - the rounding! : ) Although not sure about the mechanisms of calculation. With all the multipliers like 1.15x and 3% per point of Might etc. and combination of thereof, it's inevitable for the real damage numbers to be more complex. If all works as additions, we have damage numbers like 24.62 etc. -> Then there are perhaps two roundings applied, not knowing about each other?... For example, if the damage number before DR subtraction is 24.62, then the formula work like 24.62 - DR:6.30 = 18.32 Pierce Then, for whatever reason when showing this in game, the numbers are individually rounded by different function: - 24.62 by normal rounding -> 24.6, - 18.32 with some magic like floor(n+0.1) -> 18.4, so 24.6 - DR:6.3 = 18.4 Pierce But there are other possibilities, how that can happen... (eg. 24.66 -> floor(24.66) = 24.6 & (24.66-6.3) = 24.36 -> floor(24.36+0.5) = 24.4; etc)