You made me stop awkwardly for a minute. Did I really waste such a wall of text ? That would be hilarious.
And it is.
I have no idea how I could let this slip through the cracks of my awareness even though I use it to estimate spell damage. For some reason, I didn't apply Luck the same way the game does. The results are correct for negative Luck, since they went through the test of reality, but I expressed them using a different algorithm. If AC ≤ Thac0 -2, use Thac0 + Luck - AC = MinimumRollToHit. Otherwise, use Thaco - AC = MinimumRollToHit. Then we're back into familiar territory and know what to do with that minimum roll requirement.
The reason I couldn't click with the real game algorithm is probably because I bumped into the issue from an unexpected angle. As I was hit 100% by Yaga Shura despite a massive -17 Luck penalty, I cast Improved invisibility, and all of a sudden he turned into a kitten failing to catch a laser. WTF ? It didn't connect that with the game's algorithm the Luck penalty would be unlocked all at once with even a mere +1 AC bonus (Let's say from -9 to -10 against a -8 thac0 drunkard): I would have expected a progressive entrance of the penalty, so I put assumptions on the side and tried to find what was up from data. But I should have thought about it twice to save a lot of time, since a progressive entrance means something nonsensical: That as the to-hit tipping point (Thac0 - AC) shifts away from 1 and closer to 20, Luck's potential for reducing accuracy increases. It's clearly the opposite: Luck's penalty potential is largest when the tipping point is close to 1 and misses are otherwise rare; at -17, Luck can make use of all those points, turning a lot of hits into misses. Then as the to-hit border shifts towards 20 from an improving AC or a worsening thac0, -17 Luck becomes no more useful than -5 Luck, and ultimately 0 Luck. So the Luck penalty does a full entrance right when the to-hit tipping point enters the [1-20] range from the left, and withdraws progressively as the natural AC becomes protective enough (or the thac0 less accurate), moving the tipping point to the right.
Now I'd like to understand how the combat log computes its numbers for a non-zero Luck attacker, but I think I spent a little too much time on this Luck thing already
@Luke93 I certainly agree with your conclusion, but not your reasoning. The example you posted shows a roll of 1, with no adjustment for luck, even though negative luck of 4 is operating. The reason there is no adjustment for the roll of 1 is that luck can't reduce a roll below 1. In order to conclude that there is no impact on the chance of a critical miss though you would need to show a roll something like: - die roll 2 / 3 / 4 / 5 - luck -1 / -2 / -3 / -4 and show that would not be recorded as a critical miss (which it wouldn't).
The same applies to critical hits - it's the original die roll that determines those, not the adjustments to it.
In order to conclude that there is no impact on the chance of a critical miss though you would need to show a roll something like: - die roll 2 / 3 / 4 / 5 - luck -1 / -2 / -3 / -4 and show that would not be recorded as a critical miss (which it wouldn't).
@luke93 I'm confused now what you're trying to say. The screenshot you posted looks like it's suggesting that luck can reduce a die roll greater than 1 in order to produce a critical miss. However, as I said earlier, that's not the case - at least in BG. Here's a full screenshot demonstrating that.
I was poking around in the engine internals, and I found that several opcodes directly reference luck.
The most interesting case has to do with Mirror Image. A character's luck value directly affects whether or not Opcode #12 (Damage) will bypass the images or not.
If luck is greater than 0 -> Damage will NEVER bypass mirror images.
A mage with 1 luck and 8 images will never be hit through the images.
A mage with 0 luck and 8 images will be hit through the images some of the time.
If negative luck is less than images amount, (or luck is 0) -> Chance to bypass is (luck + 1) / (images + 1)
A mage with -5 luck and 8 images will be hit through the images (5 + 1) / (8 + 1) = 66.6% of the time.
A mage with 0 luck and 8 images will be hit through the images (0 + 1) / (8 + 1) = 11.1% of the time.
If negative luck is greater than or equal to images amount -> Damage will ALWAYS bypass mirror images.
A mage with -8 luck and 8 images will always be hit through the images.
A mage with -5 luck and 8 images will be hit through the images some of the time.
I was poking around in the engine internals, and I found that several opcodes directly reference luck.
The most interesting case has to do with Mirror Image. A character's luck value directly affects whether or not Opcode #12 (Damage) will bypass the images or not.
If luck is greater than 0 -> Damage will NEVER bypass mirror images.
A mage with 1 luck and 8 images will never be hit through the images.
A mage with 0 luck and 8 images will be hit through the images some of the time.
If negative luck is less than images amount, (or luck is 0) -> Chance to bypass is (luck + 1) / (images + 1)
A mage with -5 luck and 8 images will be hit through the images (5 + 1) / (8 + 1) = 66.6% of the time.
A mage with 0 luck and 8 images will be hit through the images (0 + 1) / (8 + 1) = 11.1% of the time.
If negative luck is greater than or equal to images amount -> Damage will ALWAYS bypass mirror images.
A mage with -8 luck and 8 images will always be hit through the images.
A mage with -5 luck and 8 images will be hit through the images some of the time.
Does that apply whether you do the standard Mirror Image Opcode (random number of images), or the set specific number of mirror images Opcode, or both?
Because I edited Mirror Image to personal taste to act as it does in (at least 3E) PnP, which requires combining both a random and a set number (1d4+level/3, max of 8). Actually, I think I got around it by doing % probability with setting specific numbers of images, necessary because at 15th and 18th, it's d2 and d3, not d4, I'd have to dig it up.
Does that apply whether you do the standard Mirror Image Opcode (random number of images), or the set specific number of mirror images Opcode, or both?
The first Mirror Image opcode (#119) just applies other Mirror Image opcode #159 with a parameter1 value equal to: 2 + (Caster Level / 3), rounded down, maximum of 8 So it doesn't matter which one you use.
Does that apply whether you do the standard Mirror Image Opcode (random number of images), or the set specific number of mirror images Opcode, or both?
The first Mirror Image opcode (#119) just applies other Mirror Image opcode #159 with a parameter1 value equal to: 2 + (Caster Level / 3), rounded down, maximum of 8 So it doesn't matter which one you use.
Hrm, I was using DLTCEP, which says for #119 "Applies the mirror image effect to the targetted creature(s), creating mirror images up to the 'Maximum Images' value."
IESDP doesn't really say much about it.
What I meant is, adding mirror images is cumulative because I had it when I tested. Vanilla mirror image is 119 for 5 images max.
Is there a difference to the luck vs. images between a spell adding 4 images 1 time, compared to a spell adding 1 image 4 times?
I have some more findings. The luck effect, does, indeed, have some say in thieving abilities:
Actions:
#18 (0x12) - Hide()
- Rolls a 1d100 in order to test for critical failure, (this being a roll of 100). Any amount of positive luck will remove the chance of critical failure. Negative luck will "shift" the probabilities slightly out of your favor. For example:
- Rolls a 1d10 to add to your base ability score when calculating success. Each point of luck will "shift" the probabilities slightly in your favor. For example:
Negative luck has the same effect, but in reverse.
Opcodes:
#252 (0xFC) Spell Effect: Set Trap
- Engine rolls a 1d100, and if the roll is less than the character's Set Traps skill it fails succeeds. Each point of luck will "shift" the probabilities slightly in your favor. For example:
- Rolls a 1d100 in order to test for critical failure, (this being a roll of 100). Any amount of positive luck will remove the chance of critical failure. Negative luck will "shift" the probabilities slightly out of your favor. For example:
It's not just the Critical Failure roll, enough luck will guarantee hiding success.
Sadly no amount of luck will help someone with zero skill for hiding/set traps. Otherwise the +5% granted by the Luck Spell could be removed for these skills. Doesn't help that the game also suppresses racial and dexterity skill modifiers for classes that don't normally have access to these skills.
A Paladin with 255 luck, (0 HiS/MS), +5 MS from Dex/Race will always fail to hide. A Paladin with 255 luck, (0 HiS/MS), +5 MS from Race, and the luck spell (+5% HiS/MS) will always succeed. A Monk with 255 luck, (0 HiS/MS), +5 MS from Dex/Race will always succeed.
- Engine rolls a 1d100, and if the roll is less than the character's Set Traps skill it fails succeeds. Each point of luck will "shift" the probabilities slightly in your favor. For example:
Negative luck has the same effect, but in reverse.
@Bubb thanks for more great analysis. Just on set traps, you've amended your post to say that setting a trap succeeds if the roll is less than your score. However, the table you've posted shows luck operating to give you an increased chance of a higher number. Is that actually an error in the game engine, or is the table you posted the one for negative luck?
@kjeron: So it does! I incorrectly believed the engine overrode the relevant register after the critical fail check, but it actually stores it away in a local variable to reuse it later
(don't ask me about the actual stealth check, though. It doesn't use a usual dice roll - something really wacky is used to calculate the roll).
@Zaghoul: The program I built to scrub all Actions / Opcodes for certain stat accesses doesn't show that Pick Pockets ever accesses the character's luck value. I've had to iron out some problems with it already, so it very well could be missing something.
Those Luck sources do stack, though. So if Luck does actually affect Pick Pockets, it very well could help. As they say, more research is needed.
@Grond0: Good eye! The engine negated the luck value before throwing it into the random function, and I accidentally plugged in the raw value when I constructed the Set Traps probability table. I've fixed it - the engine is right, I'm wrong.
No - this was one of the exploits closed by the EE.
What was closed, bard songs stacking with each other, only Enhanced Songs, something else...?
The same bard song used to stack - allowing you to have bard clones singing to multiply effects. That no longer works, but you can still have different bard songs operating together, e.g. a skald and a bard could both sing.
@Luke93 and @Grond0: How do you get that super detailed log? Is it a mod?
It's part of the unmodded game, but you can only get the more detailed information by amending the LUA file - you need the following in that:
SetPrivateProfileString('Game Options','Extra Combat Info','1')
(you may already have the line, but with a 0 rather than 1).
@Alonso: The Record screen and character portrait can both display Luck, Bad Luck, Intoxication, and Fatigue icons, but they do not specify the magnitude of the luck values from these effects. Using CTRL-M on a target, however, will display that creature's luck, among other information.
Here are the effects of the two Wish luck spells:
1. The "Bad Luck" spell uses the typical cumulative luck opcode and can therefore theoretically stack. It imposes -5 luck for 60 seconds (or 10 rounds), strikes as a level 3 spell (MGOI can block it), is dispellable, bypasses magic resistance, and affects everyone on the map, whether friendly or hostile. It is an Enchantment spell, so SI: Enchantment can block it.
2. The "Intoxication" spell uses the intoxication opcode and can therefore be blocked or cured by the Exaltation spell from Icewind Dale (also available in BG if you use the IWDification mod, and potentially available in a future EE update) or a cleric of Tyr's innate Exaltation ability. It imposes +100 intoxication, which amounts to -12 luck, for 1200 seconds (200 rounds, or 20 turns), strikes as a level 3 spell (MGOI can block it), is dispellable, bypasses magic resistance, and affects everyone on the map, whether friendly or hostile. It is an Enchantment spell, so SI: Enchantment can block it. Intoxication effects stack, but 100 intoxication is the maximum value anyway, so in practice this spell does not stack. In the most recent EE update, any healing spell appears to cure it, but in previous versions of the game, only certain spells could cure it (I believe this includes Neutralize Poison, Heal, and Greater Restoration). Standard healing potions cannot cure it, but Elixirs of Health can.
thank you @Grond0 for that information that i find very useful. i almost don't use other programs to check the game files, but i try to obtain all the information i can from the log
The unmodded game displays just the icons, i.e. the little pictures that show an effect is active - those are on both the record screen and the portrait on the main screen. If you want to see the exact effect you would need a mod.
A mage with 1 luck and 8 images will never be hit through the images.
That's incredible. Does that seriously boost Mirror Image back to its vanilla BG1 power (Stoneskin + Area of Effect damage prevention)? That would open a whole new F/M tanking tactic: Minor Sequencer of Luck plus Mirror Image, keep a second Luck memorised to rebuff after 3 rounds.
Ok, the bump of this thread made me double check if I found all of the luck applications. I found one more, and it is just kinda weird. Apparently, there is intentionally a random wait time between when a creature attempts to move to another creature, and when they will actually start pathing. Luck helps with this...
Wait Time = 0, when roll = 0
Wait Time = (8 - roll), when roll != 0
The natural roll range is [0, 7], but like many other rolls luck alters this slightly. For every point in luck the highest bound of the roll is converted into the lower bound.
So with 1 Luck the roll becomes [0, 6], with 0 having a probability of 25% instead of 12.5%. Negative luck works the same, but in reverse.
The oddity comes from the fact that 1 is the worst roll you can get, and yet it is neither of the extremes. So, -1 Luck is bad because it prevents you from bypassing the wait time, (rolling a 0), but if Luck must be negative, the lower the better.
Luck -1: Worst roll possible is a 1, you will be waiting for 7 updates.
Luck -7: Worst roll possible is a 7, you will be waiting for 1 updates!!
Positive luck will always increase the likelihood of instantaneous pathing.
Note that this wait time is only applied to creature-to-creature pathing, and never to on-the-ground destinations.
compared to most of the modern games infinity engine games have a complexity that is amazing.
a proper manual, that gives a detailed explanation of every characteristic and feature of the game would probably be a big 900 pages tome, something you can also use as ranged weapon if some goblin attacks you in the deep of the night as you are studying it
Ok, the bump of this thread made me double check if I found all of the luck applications. I found one more, and it is just kinda weird. Apparently, there is intentionally a random wait time between when a creature attempts to move to another creature, and when they will actually start pathing. Luck helps with this...
Wait Time = 0, when roll = 0
Wait Time = (8 - roll), when roll != 0
The natural roll range is [0, 7], but like many other rolls luck alters this slightly. For every point in luck the highest bound of the roll is converted into the lower bound.
So with 1 Luck the roll becomes [0, 6], with 0 having a probability of 25% instead of 12.5%. Negative luck works the same, but in reverse.
The oddity comes from the fact that 1 is the worst roll you can get, and yet it is neither of the extremes. So, -1 Luck is bad because it prevents you from bypassing the wait time, (rolling a 0), but if Luck must be negative, the lower the better.
Luck -1: Worst roll possible is a 1, you will be waiting for 7 updates.
Luck -7: Worst roll possible is a 7, you will be waiting for 1 updates!!
Positive luck will always increase the likelihood of instantaneous pathing.
Note that this wait time is only applied to creature-to-creature pathing, and never to on-the-ground destinations.
Worst roll (1):
Best roll (0):
@Bubb that delay isn't actually implemented in the game though. Can you see why in the engine - does it look like the idea was deliberately abandoned or just not coded properly?
Comments
And it is.
I have no idea how I could let this slip through the cracks of my awareness even though I use it to estimate spell damage. For some reason, I didn't apply Luck the same way the game does. The results are correct for negative Luck, since they went through the test of reality, but I expressed them using a different algorithm. If AC ≤ Thac0 -2, use Thac0 + Luck - AC = MinimumRollToHit. Otherwise, use Thaco - AC = MinimumRollToHit. Then we're back into familiar territory and know what to do with that minimum roll requirement.
The reason I couldn't click with the real game algorithm is probably because I bumped into the issue from an unexpected angle. As I was hit 100% by Yaga Shura despite a massive -17 Luck penalty, I cast Improved invisibility, and all of a sudden he turned into a kitten failing to catch a laser. WTF ? It didn't connect that with the game's algorithm the Luck penalty would be unlocked all at once with even a mere +1 AC bonus (Let's say from -9 to -10 against a -8 thac0 drunkard): I would have expected a progressive entrance of the penalty, so I put assumptions on the side and tried to find what was up from data. But I should have thought about it twice to save a lot of time, since a progressive entrance means something nonsensical: That as the to-hit tipping point (Thac0 - AC) shifts away from 1 and closer to 20, Luck's potential for reducing accuracy increases. It's clearly the opposite: Luck's penalty potential is largest when the tipping point is close to 1 and misses are otherwise rare; at -17, Luck can make use of all those points, turning a lot of hits into misses. Then as the to-hit border shifts towards 20 from an improving AC or a worsening thac0, -17 Luck becomes no more useful than -5 Luck, and ultimately 0 Luck. So the Luck penalty does a full entrance right when the to-hit tipping point enters the [1-20] range from the left, and withdraws progressively as the natural AC becomes protective enough (or the thac0 less accurate), moving the tipping point to the right.
Now I'd like to understand how the combat log computes its numbers for a non-zero Luck attacker, but I think I spent a little too much time on this Luck thing already
I think it's reasonable to assume that the same holds for a Critical hit.....
- die roll 2 / 3 / 4 / 5
- luck -1 / -2 / -3 / -4
and show that would not be recorded as a critical miss (which it wouldn't).
The same applies to critical hits - it's the original die roll that determines those, not the adjustments to it.
Yeah, sorry, I forgot to say that I modified my critical miss chance via opcode #362 (in order to see if Luck can affect it......)
In any case, (negative) Luck cannot reduce a roll below 1 ( even in case of critical misses....)
The most interesting case has to do with Mirror Image. A character's luck value directly affects whether or not Opcode #12 (Damage) will bypass the images or not.
If luck is greater than 0 -> Damage will NEVER bypass mirror images.
If negative luck is less than images amount, (or luck is 0) -> Chance to bypass is (luck + 1) / (images + 1)
If negative luck is greater than or equal to images amount -> Damage will ALWAYS bypass mirror images.
Because I edited Mirror Image to personal taste to act as it does in (at least 3E) PnP, which requires combining both a random and a set number (1d4+level/3, max of 8). Actually, I think I got around it by doing % probability with setting specific numbers of images, necessary because at 15th and 18th, it's d2 and d3, not d4, I'd have to dig it up.
2 + (Caster Level / 3), rounded down, maximum of 8
So it doesn't matter which one you use.
IESDP doesn't really say much about it.
What I meant is, adding mirror images is cumulative because I had it when I tested. Vanilla mirror image is 119 for 5 images max.
Is there a difference to the luck vs. images between a spell adding 4 images 1 time, compared to a spell adding 1 image 4 times?
Actions:
#18 (0x12) - Hide()- Rolls a 1d100 in order to test for critical failure, (this being a roll of 100). Any amount of positive luck will remove the chance of critical failure. Negative luck will "shift" the probabilities slightly out of your favor. For example:
Luck -20 Critical Failure Probability: 21%
Luck -1 Critical Failure Probability: 2%
Luck 0 Critical Failure Probability: 1%
Luck 1+ Critical Failure Probability: 0%
#28 (0x1C) - RemoveTraps(O:Trap*)
#145 (0x91) - PickLock(O:Object*)
#148 (0x94) - BashDoor(O:Object)
- Rolls a 1d10 to add to your base ability score when calculating success. Each point of luck will "shift" the probabilities slightly in your favor. For example:
1 => 0%
2 => 10%
3 => 10%
4 => 10%
5 => 10%
6 => 10%
7 => 10%
8 => 10%
9 => 10%
10 => 20%
Luck 9 Probabilities:
1 => 0%
2 => 0%
3 => 0%
4 => 0%
5 => 0%
6 => 0%
7 => 0%
8 => 0%
9 => 0%
10 => 100%
Negative luck has the same effect, but in reverse.
Opcodes:
#252 (0xFC) Spell Effect: Set Trap- Engine rolls a 1d100, and if the roll is less than the character's Set Traps skill it
failssucceeds. Each point of luck will "shift" the probabilities slightly in your favor. For example:1 => 1%
2 => 1%
3 => 1%
4 => 1%
5 => 1%
6 => 1%
7 => 1%
8 => 1%
9 => 1%
10 => 1%
11 => 1%
12 => 1%
13 => 1%
14 => 1%
15 => 1%
16 => 1%
17 => 1%
18 => 1%
19 => 1%
20 => 1%
21 => 1%
22 => 1%
23 => 1%
24 => 1%
25 => 1%
26 => 1%
27 => 1%
28 => 1%
29 => 1%
30 => 1%
31 => 1%
32 => 1%
33 => 1%
34 => 1%
35 => 1%
36 => 1%
37 => 1%
38 => 1%
39 => 1%
40 => 1%
41 => 1%
42 => 1%
43 => 1%
44 => 1%
45 => 1%
46 => 1%
47 => 1%
48 => 1%
49 => 1%
50 => 1%
51 => 1%
52 => 1%
53 => 1%
54 => 1%
55 => 1%
56 => 1%
57 => 1%
58 => 1%
59 => 1%
60 => 1%
61 => 1%
62 => 1%
63 => 1%
64 => 1%
65 => 1%
66 => 1%
67 => 1%
68 => 1%
69 => 1%
70 => 1%
71 => 1%
72 => 1%
73 => 1%
74 => 1%
75 => 1%
76 => 1%
77 => 1%
78 => 1%
79 => 1%
80 => 1%
81 => 1%
82 => 1%
83 => 1%
84 => 1%
85 => 1%
86 => 1%
87 => 1%
88 => 1%
89 => 1%
90 => 1%
91 => 1%
92 => 1%
93 => 1%
94 => 1%
95 => 1%
96 => 1%
97 => 1%
98 => 1%
99 => 1%
100 => 1%
Luck 20 Probabilities:
1 => 21%
2 => 1%
3 => 1%
4 => 1%
5 => 1%
6 => 1%
7 => 1%
8 => 1%
9 => 1%
10 => 1%
11 => 1%
12 => 1%
13 => 1%
14 => 1%
15 => 1%
16 => 1%
17 => 1%
18 => 1%
19 => 1%
20 => 1%
21 => 1%
22 => 1%
23 => 1%
24 => 1%
25 => 1%
26 => 1%
27 => 1%
28 => 1%
29 => 1%
30 => 1%
31 => 1%
32 => 1%
33 => 1%
34 => 1%
35 => 1%
36 => 1%
37 => 1%
38 => 1%
39 => 1%
40 => 1%
41 => 1%
42 => 1%
43 => 1%
44 => 1%
45 => 1%
46 => 1%
47 => 1%
48 => 1%
49 => 1%
50 => 1%
51 => 1%
52 => 1%
53 => 1%
54 => 1%
55 => 1%
56 => 1%
57 => 1%
58 => 1%
59 => 1%
60 => 1%
61 => 1%
62 => 1%
63 => 1%
64 => 1%
65 => 1%
66 => 1%
67 => 1%
68 => 1%
69 => 1%
70 => 1%
71 => 1%
72 => 1%
73 => 1%
74 => 1%
75 => 1%
76 => 1%
77 => 1%
78 => 1%
79 => 1%
80 => 1%
81 => 0%
82 => 0%
83 => 0%
84 => 0%
85 => 0%
86 => 0%
87 => 0%
88 => 0%
89 => 0%
90 => 0%
91 => 0%
92 => 0%
93 => 0%
94 => 0%
95 => 0%
96 => 0%
97 => 0%
98 => 0%
99 => 0%
100 => 0%
Negative luck has the same effect, but in reverse.
Sadly no amount of luck will help someone with zero skill for hiding/set traps. Otherwise the +5% granted by the Luck Spell could be removed for these skills. Doesn't help that the game also suppresses racial and dexterity skill modifiers for classes that don't normally have access to these skills.
A Paladin with 255 luck, (0 HiS/MS), +5 MS from Dex/Race will always fail to hide.
A Paladin with 255 luck, (0 HiS/MS), +5 MS from Race, and the luck spell (+5% HiS/MS) will always succeed.
A Monk with 255 luck, (0 HiS/MS), +5 MS from Dex/Race will always succeed.
Rabbit foot
Luck spell on Alora
Bard song active on Alora
I think this explains why Alora has never failed a PP or steal attempt in BG with a high PP score for me.
(don't ask me about the actual stealth check, though. It doesn't use a usual dice roll - something really wacky is used to calculate the roll).
@Zaghoul: The program I built to scrub all Actions / Opcodes for certain stat accesses doesn't show that Pick Pockets ever accesses the character's luck value. I've had to iron out some problems with it already, so it very well could be missing something.
Those Luck sources do stack, though. So if Luck does actually affect Pick Pockets, it very well could help. As they say, more research is needed.
@Grond0: Good eye! The engine negated the luck value before throwing it into the random function, and I accidentally plugged in the raw value when I constructed the Set Traps probability table. I've fixed it - the engine is right, I'm wrong.
@semiticgod:
- What are the two options of the Wish spell that affect luck?
- Does the game UI display the luck of a character anywhere?
What was closed, bard songs stacking with each other, only Enhanced Songs, something else...?It hasn't changed. But the effects of the bard songs are too complex to list here, so I only included the luck effects.
@ProbablyNotANumber: I'm sorry, I can't understand your posts. Maybe you can summarize a bit?
@Firecrow: Thank you for your feedback. I've updated the article with the info you provided.
@Luke93 and @Grond0: How do you get that super detailed log? Is it a mod?
It's part of the unmodded game, but you can only get the more detailed information by amending the LUA file - you need the following in that:
SetPrivateProfileString('Game Options','Extra Combat Info','1')
(you may already have the line, but with a 0 rather than 1).
Here are the effects of the two Wish luck spells:
1. The "Bad Luck" spell uses the typical cumulative luck opcode and can therefore theoretically stack. It imposes -5 luck for 60 seconds (or 10 rounds), strikes as a level 3 spell (MGOI can block it), is dispellable, bypasses magic resistance, and affects everyone on the map, whether friendly or hostile. It is an Enchantment spell, so SI: Enchantment can block it.
2. The "Intoxication" spell uses the intoxication opcode and can therefore be blocked or cured by the Exaltation spell from Icewind Dale (also available in BG if you use the IWDification mod, and potentially available in a future EE update) or a cleric of Tyr's innate Exaltation ability. It imposes +100 intoxication, which amounts to -12 luck, for 1200 seconds (200 rounds, or 20 turns), strikes as a level 3 spell (MGOI can block it), is dispellable, bypasses magic resistance, and affects everyone on the map, whether friendly or hostile. It is an Enchantment spell, so SI: Enchantment can block it. Intoxication effects stack, but 100 intoxication is the maximum value anyway, so in practice this spell does not stack. In the most recent EE update, any healing spell appears to cure it, but in previous versions of the game, only certain spells could cure it (I believe this includes Neutralize Poison, Heal, and Greater Restoration). Standard healing potions cannot cure it, but Elixirs of Health can.
Yes ----> https://forums.beamdog.com/discussion/64524/mod-reveal-hidden-gameplay-options-for-all-ee-games-patched-to-v2-0-or-higher/p1
That's incredible. Does that seriously boost Mirror Image back to its vanilla BG1 power (Stoneskin + Area of Effect damage prevention)? That would open a whole new F/M tanking tactic: Minor Sequencer of Luck plus Mirror Image, keep a second Luck memorised to rebuff after 3 rounds.
The natural roll range is [0, 7], but like many other rolls luck alters this slightly. For every point in luck the highest bound of the roll is converted into the lower bound.
So with 1 Luck the roll becomes [0, 6], with 0 having a probability of 25% instead of 12.5%. Negative luck works the same, but in reverse.
The oddity comes from the fact that 1 is the worst roll you can get, and yet it is neither of the extremes. So, -1 Luck is bad because it prevents you from bypassing the wait time, (rolling a 0), but if Luck must be negative, the lower the better.
Luck -1: Worst roll possible is a 1, you will be waiting for 7 updates.
Luck -7: Worst roll possible is a 7, you will be waiting for 1 updates!!
Positive luck will always increase the likelihood of instantaneous pathing.
Note that this wait time is only applied to creature-to-creature pathing, and never to on-the-ground destinations.
Best roll (0):
a proper manual, that gives a detailed explanation of every characteristic and feature of the game would probably be a big 900 pages tome, something you can also use as ranged weapon if some goblin attacks you in the deep of the night as you are studying it
@Bubb that delay isn't actually implemented in the game though. Can you see why in the engine - does it look like the idea was deliberately abandoned or just not coded properly?