SRL Archive - OSR Help

Hi all,

So I'm trying to use Pixel Shift to determine whether or not I'm in the process of catching an impling in one of my hunting scripts. The only problem is that sometimes if the impling sits still, it will give me a very low average pixel shift and ruin everything… A solution could be that if it's true 3 times in a row, only then will it determine if it's hunting or not.

If anyone could tell me how to wait until a function is true more than 1 time in a row, that'd be awesome!

Thanks.

Here's what I'm using btw;

function IsHunting: Boolean;
var
  PBox: TBox;
begin
  PBox := IntToBox(238, 139, 267, 177);
  Result := (AveragePixelShift(PBox, 500, 750) > 220);
end;   

Uh well it won't excactly answer your question, but in our reflection include you could see if a npc is animating. That should help.

I know how this goes all too well. I had the same trouble with determining of our player was fishing with a small fishing net. The animation uses a lot of pixelshift when the player bends down or stands up, but while the player is bent over netting the shift is low, but we remain fishing. I got around this by using the same idea you have, koryperson. Your logic is right so nice job so far.

To put exactly what you want in code it would look something like this:

function isHunting(): Boolean;
var
  PBox : TBox;
  i    : integer;
begin
  Result := False;
  PBox := intToBox(238, 139, 267, 177);

  for i:=1 to 3 do  //1..2..3 times
    if not result then
      Result := (averagePixelShift(PBox, 500, 750) > 220);
end;

I'll be happy to explain this if you'd like. Also, for the record, it makes me happy to see people using pixelshift for such things. :smile:

koryperson made flight happy, what a wonderful day!

Just a note. I had something similar in my woodcutter (see sig) that uses a median of pixel shift values. What I learned was that pixel shift was easy to put in but hard to tune to work right, let alone work right for different people (in the case of detecting character animation across different costumes). The biggest problem is that some costumes have huge pixel shifts during their standing idle animation, more than you get during a lot of activities. As such, I actually recommend not using pixel shift if there are easier alternatives for a given situation.

From: vwxz
Just a note. I had something similar in my woodcutter (see sig) that uses a median of pixel shift values. What I learned was that pixel shift was easy to put in but hard to tune to work right, let alone work right for different people (in the case of detecting character animation across different costumes). The biggest problem is that some costumes have huge pixel shifts during their standing idle animation, more than you get during a lot of activities. As such, I actually recommend not using pixel shift if there are easier alternatives for a given situation.

imo pixelshift is great IF you combine it with other things like xp drops/change and other things that could change

From: vwxz
Just a note. I had something similar in my woodcutter (see sig) that uses a median of pixel shift values. What I learned was that pixel shift was easy to put in but hard to tune to work right, let alone work right for different people (in the case of detecting character animation across different costumes). The biggest problem is that some costumes have huge pixel shifts during their standing idle animation, more than you get during a lot of activities. As such, I actually recommend not using pixel shift if there are easier alternatives for a given situation.

Pixelshift will still work great for any kind of animation, and for any specific target you're tracking. You could get a TPA of a certain color (for example your player's top & bottom) and calculate the amount of pixelshift of that TPA only. And, as you brought up certain outfits would effect it because of size. Well for this you don't have to use a static pixelshift count, instead use a percentage. Take a look at how MonkFishies detects a whirlpool:

Function foundWhirlPool(Me: TEntity): Boolean;
var
  b  : TBox;
  l  : Integer;
  tpa: TPointArray;
begin
  result := false;
  b      := intToBox(myPlayer.BasePnt.X-17, myPlayer.Bounds.Y1-30, myPlayer.BasePnt.X+17, myPlayer.BasePnt.Y-5);
// Box "b" is directly north of our player
  colorToleranceSpeed(2);
  setColorSpeed2Modifiers(1.58, 0.29);
  findColorsSpiralTolerance(MSCX, MSCY, tpa, 12433082, b.X1, b.Y1, b.X2, b.Y2, 13);
  setColorSpeed2Modifiers(0.02, 0.02);
  colorToleranceSpeed(1);

  l := length(tpa);

  if (l > 20) then
    result := (getPixelShiftTPA(300, tpa) >= (l/6)); // If 1/6 (17%) of this TPA is moving then...
end;

From: hoodz
imo pixelshift is great IF you combine it with other things like xp drops/change and other things that could change

Definitely agree. If you have multiple methods that are independently accurate most of the time, doing some sort of voting between them really helps improve your overall accuracy.

From: Flight
Pixelshift will still work great for any kind of animation, and for any specific target you're tracking. You could get a TPA of a certain color (for example your player's top & bottom) and calculate the amount of pixelshift of that TPA only. And, as you brought up certain outfits would effect it because of size. Well for this you don't have to use a static pixelshift count, instead use a percentage. Take a look at how MonkFishies detects a whirlpool:

That's really clever!

Yea, the problem is less with pixelshift as a whole and more with pixelshift on the main screen character (i.e. something that changes from user to user and not necessarily in the scripter's control). There's certain outfits that have extremely high variance in pixelshift doing anything, where the ranges you can get while idle and the ranges you can get while chopping etc. overlap a great deal. In my setup instructions, I tried to tell people to use solid colors, but then someone sent me a screenshot of a bad case with a specific solid color.

Thanks for the idea to narrow down the pixelshift area. Will definitely explore that further if/when it comes up in my scripting.

From: Flight
I know how this goes all too well. I had the same trouble with determining of our player was fishing with a small fishing net. The animation uses a lot of pixelshift when the player bends down or stands up, but while the player is bent over netting the shift is low, but we remain fishing. I got around this by using the same idea you have, koryperson. Your logic is right so nice job so far.

To put exactly what you want in code it would look something like this:

function isHunting(): Boolean;
var
  PBox : TBox;
  i    : integer;
begin
  Result := False;
  PBox := intToBox(238, 139, 267, 177);

  for i:=1 to 3  //1..2..3 times
    if not result then
      Result := (averagePixelShift(PBox, 500, 750) > 220);
end;

I'll be happy to explain this if you'd like. Also, for the record, it makes me happy to see people using pixelshift for such things. :smile:

Thanks, this is awesome x)

I've never even bothered using the i = # to # things because I don't quite fully understand them. Does it just run the if then statement until it's true 3 times(in this case)?

From: koryperson
Thanks, this is awesome x)

I've never even bothered using the i = # to # things because I don't quite fully understand them. Does it just run the if then statement until it's true 3 times(in this case)?

a for loop just does something over and over the specified amount of times.

for i := 0 to 3 do//0, 1, 2, 3(total of 4 times)
begin
somethingHere();
end;

From: koryperson
Thanks, this is awesome x)

I've never even bothered using the i = # to # things because I don't quite fully understand them. Does it just run the if then statement until it's true 3 times(in this case)?

It just so happens NCDS wrote a very detailed tutorial on loops that you can read HERE.

From: Flight
It just so happens NCDS wrote a very detailed tutorial on loops that you can read HERE.

Thanks so much for the help! I've read through that tutorial before but now it actually makes sense. Thanks again!