Sprinting usually sends the camera FOV past the standing FOV of 51 into the 53+ range. Going any lower leaves any ADS modes unusable due to lack of zoom.ĥ2 being the highest desirable number to modify. This works by checking if the FOV as stored in game memory meets the condition of being between 39 and 52 (also checking if leaning).ģ9 being the lowest desirable number to modify.
#Rainbow 6 vegas 2 pc language settings change code
I'm gonna build up a beta Trainer for this to enable the code change that also allows for changing the amount the FOV is modified and post it up later. CT file for your examination/criticism (kind of messy and stuff but progress is progress, right?). Still has weird anomalys but i will upload the. Very limited use case thus far but it catches all the instances that i'd want to change the FOV (Standing, Crouching, Sprinting Etc) while leaving alone more precise aiming modes. In the event that first check is less or second check is greater, it just executes standard FOV routine so it only changes anything between 49.725 and 62 (49.725 being crouching FOV and 61.something being sprint FOV). If less or equal, run the code to add into the process (with adjustable FOVVALADD, if zero it won't add anything) Went back to the drawing board and finagled some way of having a readily modifiable FOV with caveats. and all of the floats in xmm register tend to stay the same:Įither way, i'm getting to my wit's end with this because it seems like i can't get all the information i would need and how esi and edi are determined because of how many esi and edi addresses are written (4). i have tried looking through XMM and FPU Registers (which is how i found the FPU tidbit) but apart from base FOV being stored in FPU Xtend, no useful info is there from what i can tell. because from what i can tell, the st(1) value is then what goes into. what is not so clear is *how* and what values it is processing then storing in st(1). causing major glitches, indicating that the multiplication is a vital component in determining FOV. Noping the fmul instruction completely messes up the FOV. using the address of the useless memoryspace as a pointer gets me nothing of value either. Using the address of the FOV that gets "written" to as a pointer just points to the useless memoryspace. I tried putting in some of the pointer addresses to find out what it points to but that leads to nothing but useless areas of memory. what it does is put a pointer to something else when another FOV is needed (such as zooming). It doesn't straight up write float values to EDI bar 51. meaning that it seems like a looping cycle of resets to the value it sees it "should" be. it seems that some addresses get re-used for both ESI and EDI in looping instructions. i say that because of something else:į*****g non-existent. so i can only assume that either fld edi is loading it into extended FPU or something else is.
The Extended FPU Register between fmul and the fstp esi command contains the base FOV. the only other *things* i've found since that have been: "R6Vegas2_Game.exe"+31F9B9: D8 C9 - fmul st(0),st(1)and try as i might, i can't get anything intelligible out of that because i can't find what for the life of me is on those stacks in terms of values. Okay, looking at it, the one function i have fundamentally no understanding as to it's contribution is
0 kommentar(er)
