SolarStrike Software

I've been trying to figure out why the bot can't move properly when mounted. At first I thought it might be a timing issue because it moves faster but it looks like it has something to do with the players x,z values.

The players x,z values seem to be stable when not mounted but fluctuate wildly when mounted.

So obviously that means the values in the memory addresses are fluctuating when mounted.

So I thought "Maybe there are other memory addresses that don't fluctuate when mounted" so I had a look for them.

I found 4 addresses (for the x value) that are stable when mounted and not mounted.

Is it possible to use these instead?
0187E4B8
0187E780
018DF994
0350E510

I couldn't find offsets as there were no "copy memory" values. Does that mean they're static?

Please correct me if you are already aware of all this.

Edit: I've since checked this again. Looks like they aren't static. I've come up with another 4 values whose endings are the same as above but the starts are different. I just checked the value of staticbase_char and it matches the first 2 values ie. 0187E000. Can we use staticbase_char and an offset of 4B8 or 780 to find these values? I'm not sure I understand offsets as I don't see the pawnX_offset value. Is it supposed to be 0187E028 as the above example 'cos that's not there?

I think you could be right. This might cause it to unstick even when it's not necessary. It looks like it only varies a small amount, so it shouldn't be too much of a problem to use those numbers anyways.

Find this in player.lua: Try wrapping that in an if-statement so that it only triggers when not mounted( if( not self.Mounted) ). That might fix it.

Administrator wrote:I think you could be right. This might cause it to unstick even when it's not necessary. It looks like it only varies a small amount, so it shouldn't be too much of a problem to use those numbers anyways.

Find this in player.lua:

Code: Select all

		if( os.difftime(os.time(), self.LastDistImprove) > 3 ) then
			-- We haven't improved for 3 seconds, assume stuck
			success = false;
			failreason = WF_STUCK;
			break;
		end

Try wrapping that in an if-statement so that it only triggers when not mounted( if( not self.Mounted) ). That might fix it.

The unsticking doesn't happen often so it doesn't bother me. The thing I'm trying to fix is the way it wobbles left and right. It's as if it's unable to point the player in the right direction. Another idea was maybe the addresses for direction might also have a problem. But player.Direction seems steady, mounted or not. Note, I use quick turn.

Is there no way to try the stable addresses to see if it stabilizes the mounted movement?

You could try it by swapping out the addresses in CPlayer:update(). Just use the address you've found with Cheat Engine and don't bother with pointers unless it actually fixes the problem.

I doubt that's the cause, though. Really, I think the simplest solution would be to just ignore the QUICK_TURN option while mounted.

Administrator wrote:You could try it by swapping out the addresses in CPlayer:update().

Code: Select all

self.X = memoryReadInt(getProc(), use_the_address_here);

Just use the address you've found with Cheat Engine and don't bother with pointers unless it actually fixes the problem.

I doubt that's the cause, though. Really, I think the simplest solution would be to just ignore the QUICK_TURN option while mounted.

You were right it wasn't the x, z values. I really didn't expect it to be as they are so close, if they were causing wrong angles to be calculated, it would only be by a small amount not the 45 degree waggle that it does. Turning QUICK_TURN of doesn't really help as it still waggles but more slowly.

I had another look at the calculated angles and made a discovery. faceDirection doesn't work at all when mounted. I'd say this must be the cause of the problem. Maybe you need to find other addresses to write the vectors to, when mounted, to turn?

You didn't have a comment to make about QUICK_TURN not working when mounted?

I found the addresses and pointers to apply the vectors to when mounted. I've done a bit of testing and they seem to work perfectly.
To get to the addresses you start with;
addr1 = staticbase_char
addr2 = addr1 offset by charPtr_offset
addr3 = addr2 offset by 7c or 278 (they give the same address)
X vector address = addr3 offset by pawnDirXUVec_offset
Y vector address = addr3 offset by pawnDirYUVec_offset

Although I've found these addresses I think implementing it would be beyond me. Can you implement these please?

I tried doing it myself:
I added to addresses.lua

and changed faceDirection in player.lua like this. but it crashes the client when mounted.

I suspect I just don't understand the memory functions and have used them incorrectly.

Can anyone see what is wrong with this?

By trial and error I figured it out. It was supposed to be There's just 1 small thing that I'd like to fix before committing this. At about half the waypoints it will face backwards then forwards again before continuing. I suspect it has something to do with the character getting to the waypoint faster than the script expected. I still haven't found how to fix it yet.

All sorted.

Committed to rev 464.

very useful,thank you

miximixi007 wrote:very useful,thank you

Nice to have someone finally notice.

rock5 wrote:Nice to have someone finally notice.

I don't mean to overlook what you're doing. I, and I'm sure everyone here, appreciates the work you are doing. A few of my accounts were disabled, which makes testing some stuff pretty difficult.

Administrator wrote:

rock5 wrote:Nice to have someone finally notice.

I don't mean to overlook what you're doing. I, and I'm sure everyone here, appreciates the work you are doing. A few of my accounts were disabled, which makes testing some stuff pretty difficult.

Actually I said it in jest. I wrote it with a smile on my face. Anyway, I wasn't talking about you. I guess I just expected a few more positive comments to bolster my ego. In the end I do it because I enjoy it and that's the important thing.