Leaderboard

View File BadCase's Il2Cpp Fields This script allows users to edit field offset values in instances of Il2Cpp classes by entering a class name, this means no offsets are needed. As long as class and field names are not changed in the game the edits will continue working even after a game updates. Create Edit (Enter Class Name) Here you will enter a known class name to search for instances and create an edit. Edits you create for a game are added to the main menu above this menu item. Create Edit (Search Il2CppDumper Dump) Here you can load a Il2CppDumper dump.cs and search for keywords to find class names, search for instances and create an edit. Edits you create for a game are added to the main menu above this menu item. Import Edits Here you can import edits created and exported by other users of this script. Export Edits Here you can export edits you have created to share them with other users of the script. Delete Edit Here you can delete edits for a game and remove them from the main menu. Submitter BadCase Submitted 02/07/2022 Category Tools  

This understanding is based on fundamental misconception that GG automatically updates anything in tables that have been returned with "getResults", "getValues" or other GG API functions. GG not only doesn't do that, but also wouldn't be able to do that without significant performance impact (just imagine having to read values from process memory for all elements of all tables that have been returned by GG API functions every N milliseconds). So changes in process memory "automatically" don't affect anything in script anyhow. To get updated data from process memory, corresponding GG API function ("getValues") needs to be called, but even it doesn't change anything in table that is passed to it as argument, instead it returns new table that has new values in "value" field of it's sub-tables.

There is one other detail regarding the comparison to "0" (string). Behavior of comparison operators for this case is described in the manual as follows: For our case it means that the following condition _x[i].value ~= '0' will always evaluate to "true", because "value" field has value of number type. Correspondingly, correct comparison to check for value being not equal to zero is: _x[i].value ~= 0

No, that's because all values of the table are explicitly set to value of first element when the following code is executed: for i = 1, #x do x[i].value = x[1].value end If, for example, "x" has 3 elements, the loop is then equivalent to: x[1].value = x[1].value -- value of first element is set to itself x[2].value = x[1].value -- value of second element is set to value of first element x[3].value = x[1].value -- value of third element is set to value of first element And then, when next loop is executed: for i = 1, #x do x[i].value = x[2].value end "x[2].value" no longer has it's original value, because new value (of "x[1].value") has been assigned to it during execution of previous loop. This is why only first loop works as intended and all subsequent ones don't. And this is why copy of values needs to be created before the first loop (to have access to original values after table values have been overwritten).

Just for the info if anybody needs it - the version "rr3_race_mode.v9.8.2.3.7.bin.lua" works in 10.2 Cheers