lalakobe

Well, it's still a bug, that prevented player from getting some of the roll results.

I patched executable once again to use inside rand() function RDRAND CPU instruction (https://en.wikipedia.org/wiki/RDRAND). This instruction is available up from Ivy Bridge Intel architecture (my cpu is old, but luckily has support). The only drawback is that RDRAND is 2x-3x slower (at least on my CPU) that classic C++ rand() implementation, thus autorolling takes more time. And here is the result:

If 05 is changed to 02, race is not changed, it stays ELF, just this code (rolling for EXC_STR) is skipped:

By using x64dbg debugger I looked at the whole "press reroll button" process. It saves roll result ("good" ones, fitting into race and class restrictions) into memory after each stat generation (first, STR, then DEX etc.), six times. This memory segment looks like this: STR EXCEP_STR INT WIS DEX CON CHR 17 36 11 12 11 12 11 (for example) I thought that maybe some function altered these number afterwards, so I set up breakpoint on write to these addresses, but no luck. After that, I tried altering rolls in the memory in debugger on the fly (I thought maybe some kind of overflow happens, that silently discards high rolls). So, I changed each stat to 18 during generation, and program wrote these numbers into memory as intended without any errors, and I got 108 roll on screen in game. So, this process works fine. Last thing that I can think of is some kind of overflow in rand() function, maybe tied with seed as you proposed. By changing racial condition, as I described before, I disabled additional EXC_STR roll, that happens before stat rolls, for ELF, and 104 rolls became a)unstuck and b)much more frequent. I think Ihave to look at rand() implementation in EE more closely.

Continuing my research Algorythm for exceptional STR is: 1. Check if race <> HALFLING (as halfling max STR is only 17) 2. Call rand() function, get number from 1 up to 32767, for example 20461 3. Get last two digits of this random number, 61 in this example 4. Add 1, result is 62. Thats it, exceptional STR is 62 in this roll Another interesting thing, as an experiment, I changed racial condition from halfling to elf in executable (by changing byte from 05 to 02), launched autoroller, and 104 rolls became "unstuck":

Thanks for the tip, here is what I found using Ghydra (although my knowledge of C++ is very low, last time I used it to make a program was like 15 years ago, so my assumptions may be wrong, happy if someone corrects me) Reroll button (OnAbilityReRollButtonClick) calls ResetAbilities function. ResetAbilities does some checks (for example for Halfling race) and calls rand() function to reroll exceptional STR (rand() seems to be Microsoft rand implementation: my_rand_gen->seed = (my_rand_gen->seed * 214013 + 2531011); return (my_rand_gen->seed >> 16) & 0x7fff;) After that, it calls ResetAbility function for each stat (until it returns 1) and checks if total sum is above 75. Then, UpdateAbilitiesPanel is called to redraw new numbers on screen. ResetAbility also uses rand(), converts its output to 1-6 range, and repeats 2 more times, basically doing 3D6 roll. After that, it checks for racial and class restrictions, if that check fails, function returns 0, so it is fired again, until correct number is rolled. Inside ResetAbility there are however some strange varibles, I cant understand how it got its value.

Lower rolls (103) working as intended

My goal is not to create ultimate elf ranger, I just want to understand, if 105+ rolls are even possible in bg:ee (and bg2:ee, as I get the same stats distribution there) or there is some bug, or bad randomizer (I remember back in the days in GW-BASIC you had to execute RANDOMIZE TIMER command before any randomizer stuff, or else you would be getting same "random" numbers again and again ). To check, if rolls were identical or not, I modified output (if chargen.totalroll >= 104 it shows concatenated chargen.ability[ from 1 to 6 ].roll) and here what I got:

Doing some autorolls now, added some info in ui.menu All three 104 rolls were the same - 18/54 17 17 18 17 17

Yes, I see higher individual numbers often (like str 18/00 or dex 19) on lower total rolls, but after some time I eventually get up to 104 and 104 has the exact same distribution (18/54 17 17 18 17 17)

Still, I always get the same 18/54 STR every time in BG1-ee AND BG2-ee. Could it be a bug in engine? I wanted to look at source code but I'm not sure, if rolling algorythm is in scripts inside archive files or some subroutine in executable.

Hi everybody! Can somebody help me, I want to solve this problem: I found strange behavior during abilities roll on character creation in both BG:EE and BG2:EE. I used autoroller mod to try to get high rolls. Looking at autoroller source code (override/ui.menu), all it does - just presses standard in-game button REROLL many times. I tried to roll on ELF-RANGER character. I noticed that my highest rolls were all 104, but furthermore, each highest (last achieved) roll had the same stats distribution. For ELF-RANGER these are: STR 18/54 DEX 17 CON 17 INT 18 WIS 17 CHA 17 I never saw 105+ roll, even after few days of non-stop autoroll. 104 roll appear after 3-15 minutes of rolling. I tried exiting and restaring the game, reinstalling the game, rebooting PC - max rolls were the same. I asked my friend to buy BG:EE, install it, install autoroller and try to roll same ELF-RANGER character. He got the same 104 roll with same stats distribution. I installed BG2:EE with another autoroller (https://github.com/r-e-d/EEUITweaks/releases) and tried to create ELF-RANGER in BG2. Guess what - same 104 roll with same stats distribution. I reproduced these results many times with same outcome. And another thing - me and my friend also tried to roll HUMAN-PALADIN on two different PCs. We also got exactly same highest rolls many times. These are different from ELF-RANGER. Total: 103 STR 18/86 DEX 17 CON 18 INT 17 WIS 16 CHA 17 So, do you know what script produces these rolls in Infinity Enfine?