Not quite there in a deep sense. I understand what’s happening in these simple sorts, but I’ll be hunting for more complicated examples in the web to gain further understanding.

My interpretation is that the sort expects pcs.A to be a table to be sorted by the third element of the table (because the function references that index) in ascending order.

If I parse lines w (a table indexed by line number), split each line into a table of 9 elements by a split_by_space function where 3 is an xPosition and 4 is a yPosition, I could sort it as so?

Code: Select all

```
table.sort ( w, function( a, b )
return kwikDistance ( a[3], a[4], xo, yo ) < kwikDistance ( b[3], b[4], xo, yo )
end)
```

If that would work then I’m making progress! Hey, I just discovered the EXPAND VIEW and COLLAPSE VIEW buttons in this forum!

What I could use is a sort of a more complicated structure built as

w[1][1] = { (9 elements where 3 and 4 are an xPos and yPos, and element 6, say, is a size) }

w[1][2] = { ( a table as above) }

w[1][3] = { (ditto) }

w[2][1] = { (ditto) }, w[2][2] = { (ditto) }, w[2][3] = … etc.

First sort by size when w[1] is fully populated before w[2] is created seems simple to do

Code: Select all

```
table.sort( w[1], function (a,b) return a[6] < b[6] end )
```

Then sort by distance of w[1][1] versus w[2][1] by the largest elements of each w

* only, without losing the first sort result*

Code: Select all

```
table.sort( w, function (a,b ) return kwikDistance( a[1][3], a[1][4], xo, yo ) < kwikDistance ( b[1][3], b[1][4] ) end)
```

Wanting the result where w

*[1][6] > w**[2][6] > w**[3][6] … then ordered as w[1]s are nearer to xo, yo than w[2]s and w[2]s nearer than w[3]s as sorted only by the kwikDistance of w**[1]. At this point I’m better off testing the output by trial and error. Seems I need a stand-alone interpreter to play with. *

But if the table were to be created without the intermediate sort, and I wanted to sort it all in the end, then it gets even more interesting.