Cheat Engine

mgr.inz.Player · Posted: Wed Jul 17, 2013 1:12 pm Post subject:

As you wish. It will be the same as first.

shadowpt · Posted: Wed Jul 17, 2013 1:46 pm Post subject:

@mgr.inz.Player

It did something! And the game hasn't freaked out (which is a big plus)

I have set the float value to 5.0 because the smaller ones weren't noticeable and now the vehicle changes speed so fast! I mean going from 90 to 0 in a sec (it normally just slows down, definetly not that fast) and to 90 again in a sec or less.

BUT it is not really speedhack because the vehicle still retains it's max speed limit (which is confusing :/ ) so this is altering how fast the speed variations are beind made but not the speed itself (?) or it is altering the speed increments but the max speed is unchanged.

My brain stopped working after that one, this is very strange.

Edit: Sorry I always quote when I shouldn't, quote removed.

Wait, nevermind, I just saw one vehicle spazzing out when I turned the script on and going back to normal when I turned it off, you are correct, that opcode is really affecting other vehicles which I might have missed because they render out and in of distance and when that happens the opcodes may or may not affect them.

Well this makes much more sense now... But why modifying the movss [eax+30],xmm0 only affects my vehicle and not the others?

mgr.inz.Player · Posted: Wed Jul 17, 2013 1:56 pm Post subject:

"it is altering the speed increments but the max speed is unchanged"
Yes, we changed acceleration (aka speed delta).

Now we can change above script that way:
- if delta is below 0, we don't do anything. normally slow down
- if delta is above 0, we multiply it by our factor.

- if delta is very close to zero (but still positive) and vehicle is still below our new buffed maximum speed limit, we change it to bigger value, otherwise, we just zero it.

shadowpt · Posted: Wed Jul 17, 2013 2:07 pm Post subject:

@mgr.inz.Player

But I am still left with the problem of filtering the delta for my own vehicle, which proves you were right.

I wonder if these 2 other opcodes that write to the velocity address have anything that can be changed to achieve this result.

mgr.inz.Player · Posted: Wed Jul 17, 2013 2:20 pm Post subject:

Right click on this opcode, and test how many addresses it access.

movss [eax+20],xmm7

shadowpt · Posted: Wed Jul 17, 2013 2:32 pm Post subject:

I see, that is something I should have done already, will do it right away for that one and the other fstp aswell.

Also I modified the script to change

mgr.inz.Player · Posted: Wed Jul 17, 2013 3:23 pm Post subject:

I repeat myself: take your time.
Read about "shared code" and "structure dissect".

shadowpt · Posted: Wed Jul 17, 2013 5:30 pm Post subject:

daspamer · Posted: Wed Jul 17, 2013 7:17 pm Post subject:

shadowpt · Posted: Wed Jul 17, 2013 7:49 pm Post subject:

@DaSpammer

That works 50% well! I guess it's my fault that I didn't mention the velocity also reaches negative values (when the vehicle is going South) and when I use your fix during the negative driving it will instantly set 125.

So if I am with 35 speed heading south, speed is -35. If I activate that script at that moment, -35 becomes 125.

Also it is making all vehicles fly towards north at the same time.

daspamer · Posted: Wed Jul 17, 2013 7:53 pm Post subject:

Edit:
Wait, your speed is below 0, and it goes to 125 instantly,strange.

__________________________________________________________

shadowpt · Posted: Wed Jul 17, 2013 8:13 pm Post subject:

It's almost perfect! Now it sets the limit right when it is going North and doesn't auto set when going south BUT it also doesn't seem to do anything now when going south, the velocity remains unchanged when the limit is breached.

I watch the velocity changing when I go north and once I reach the 125 it sits there perfectly still at 125 but when I go south and it reaches -125 it doesn't stay there, it just increases to -130 and so forth.

EDIT: I think that is because the function is jumping to the original code when the limite is lower or equal to 0 so it is not setting any negative limit like the positive limit is.

Should it be

shadowpt · Posted: Thu Jul 18, 2013 3:43 pm Post subject:

Well I have been doing what you said, trying to find the id and stuff like that, re-read the scrutcture dissection lots of times and did as it suggested, read the shared code too.
Nothing worth using was found, no ID's or things like those, all the vehicles share the same structure or stack sperated by symmetric distances and they all hold the same fields (velocity, position, etc).

I did find out that the addresses for my vehicle writen by that opcode usually stand in the last place when they are sorted and I say "usually" because I have yet to see them elsewhere beside's the last row. Don't know what I could do with this because I already have the pointers for each of those addresses.

I also tried to find the address for the increment value that is specific to my vehicle (?) but I couldn't find anything worth using, modified every single value from all the addresses written by, accessed by and the respective eax and esi (yes I even went after the esi) but none of those changed a thing when I moved, they are probably just placeholders for other things which I know nothing of.

And this is it, what I am left with is mgr.inz.Player's first idea, DaSpamer's great fix and a lot of new things I learned.

Regarding the code + DaSpammer's fix, it works great, the limits activate perfectly well when they are reached and they work for negative and positive values as intended.

Now my problem is that these are vectors (like mgr.inzPlayer said) and they will add up even when one or two limits are reached, let's say I am going north at 25 (25 being my limit) west or south still haven't reached the limit so they start adding up until they reach the limit, same goes for the height speed. I end up moving in spatial diagonals when all 3 reach the limit which is kinda hard to maneouver (can't do it at all actually).

What I would like to do now is to sum the 3 vectors (their modules so no negative value subtracts the positive values), verify if the total scalar velocity is 25 or above and then act accordingly: If it is above 25 then block that limit, if it is below the limit then let it work as normal.

But this might be very complicated to do with assembly, I think, so I understand if no one wants to give a hand with this.

Basically this is what I would like to do:

Limit check:
->Check if X Y or Z have negative symbol and store for later
Sum the modules of X Y and Z velocities
Compare the above sum result to the limit
If the sum is above or equal to the limit then lock it
If it is not then do nothing

Proportional speed multiplier:

Sum the modules X Y and Z velocities
Compare the X Y and Z to the sum and return a percentage for each one
Multiply the speed multiplier with the percentage returned for each axis
Replace each velocity with the respective speed multiplier
->And this is where the negative symbol is used on the respective axis if one was present.

Hope this isn't too confusing. Can I use math operations mixed with assembly code? X+Y=123 and so on?

EDIT: Better to elaborate on what I said

daspamer · Posted: Thu Jul 18, 2013 4:37 pm Post subject:

[x]+[y]+[Z] = 23.30.

And you may use math, by doing mov, sub,mul and etc.
Also
You can check if the value increases OR decreases, by doing this for example:

shadowpt · Posted: Thu Jul 18, 2013 4:54 pm Post subject:

Oh wow, that sounds awesome and simple!

Although I still have to get used with the order of the functions and the one you posted presents a problem, it will just affect 1 opcode line (the one for North/South velocity) which cannot retrieve the total value of the velocity, it will still need to address 2 more lines (West/east and Up/down opcodes) which are mainly the eax+34 and eax+38

This is going to be challenging Shocked