Multiple Index trouble

[Superslayer]

I'm sure I've seen this setup in other scripts or at least have heard about it.  So here's the general run down of what I'm trying to set up.

finditem ***
when > 0
run the #index
WITHIN that same #index
index those with %this distance
&
index those with %that distance
move char to %this distance in %this index
then
move char to %that distance in %that index

here's what I'm working with in case my pseudo code sucks

Code: [Select]

  finditem %bla G_23
  if #FindCnt > 0
  {
    set %lowX
    set %lowY
    set %highX
    set %highY
    set %lowcnt
    set %highcnt
    set %lowindex
    set %highindex
    Set #FindIndex 0
    Repeat
      Set #findindex #findindex + 1
       if #finddist =< 7
        {
         set %lowindex #findindex
         set %lowcnt #findcnt
         set %lowcnt %lowcnt + 1
        }   
    if #finddist <= 15
        {
         set %highindex #findindex
         set %highcnt #findcnt
         set %highcnt %lowcnt + 1
        }
     Until #findindex = #findcnt
     for %lowindex 0 %lowcnt
     {
       set %lowX #findx
       set %lowY #findy
       move %lowX %lowY
       ignoreitem #findid
     }
     for %highindex 0 %highcnt
     {
       set %highX #findx
       set %highY #findy
       move %highX %highY
       ignoreitem #findid
     }
  }

So essentially, find all the Id's within this range, and seperate them into a distance variable.  Then, move to each location one at a time starting with the closer range index first, then the further one.

Thank you very much in advance

[TrailMyx]

This might give you some ideas.  Here's a sub that will locate all requested items of item type %bla and return them in ascending order in the following variables:

%index = number of items found
%findx0, %findy0, %findz0, %finddist0
%findx1, %findy1, %findz1, %finddist1
%findx2, %findy2, %findz2, %finddist2
...
etc = locations of items and their distances, all in ascending order

Code: [Select]

sub FindObjects
  set %index 0
  ignoreitem reset items
  for %i 1 23
  {
    finditem %bla G_ , %i
    if #FINDCNT > 0
    {
      for #FINDINDEX 1 #FINDCNT
      {
        set %findx . %index #FINDX
        set %findy . %index #FINDY
        set %findz . %index #FINDY
        set %finddist . %index #FINDDIST
        set %index %index + 1
        ignoreitem #FINDID items
      }
    }
  }
return

I'm not sure if this is exactly what you want, but I whipped it up for you anyhow.  Perhaps it'll give you something else to think about. 

The only minus about this code is that it does do a bunch more finditem calls.  No real biggy because the code is now more elegant and easier to understand.

[Superslayer]

Thank you TM.  That certainly does clean up my mess  . I was hesitant on using the '.' & ',' operators in the event I'd once again over complicate things.  Turns out I was right and wrong at the same time  !  Time to experiment and test those operators to get something moving.

[TrailMyx]

You're welcome SS.  You will find that the "," and "." operators can be your friend so it will be well worth the time looking into how to wield them.  I've tried a couple times to explain their function, but I tend to overcomplicate them.  The real difference is these are evaluated oppositely.

Comma operator (evaluated left to right):
Example:

Code: [Select]

set %test1 booya
set %test 1
set %one %test , %test
display %one
stop

results:   11

Dot operator (evaluated right to left)
Example:

Code: [Select]

set %test1 booya
set %test 1
set %one %test . %test
display %one
stop

results:   booya

You'll see the Comma operator acts as a classic concatenation operator, but the Dot operator acts as a classic index operator.

[Superslayer]

By your example, it would seem to me that the "." will be the chosen operator atm for my specific task at hand.  Some of the other examples I've seen and read were still imo, very vague and not very 'noob' friendly.  I actually had to look up the word 'concatenation' when I first came across it on euo.  Needless to say, none of my personal little scripts use either the ',' or '.' operators.

[TrailMyx]

You will find that you'll need to test that part of the code pretty thoroughly and even single-step through the code to be sure the resulting evaluations are what you expect.  Frankly, I spend a bit of extra pre-debug time with that type of code too.  The problem with these operators are that sometimes they don't evaluate quite like you think they should.  So test test test!

[Superslayer]

Amazingly enough, I did just now happen to find an old euo forum board discussion on the (.) & (,) operators.  I figure that before I do do as you suggest "test test test!" , I had better know a bit more about the operators, what is happening, and most importantly, Why !  Here's the link to where I read about them in case it interests you and anyone else reading this post.

Old EUO Forum Linky

[TrailMyx]

lol, I miss those old forums.  Back in the day when they weren't so grumpy too.  heh

[Superslayer]

  hehe, they do look a bit stressed and discombobulated