Hexagon edges are labeled (by number) in the white group, thanks to seam adjustments in the purple group. What has befuddled me is the light orange group - ridiculously COMPLEX 
I must be missing something 
It can’t be that difficult to find points near curves? 
No takers? I hoped someone would show me a better way?
I found a way to slightly simplify the light orange group by eliminating Duplicate Data and Partition, connecting Series (‘V’ isocurve indices) directly to Sort List ‘A’ input:
But it still seems more complicated than it should be?
Hello, I had a large weekend, I still checking the definitions the last looks perfect, but When I try to matching the lists doesnt seems works, 0 must be 0, what is the correct way in this case to match sorry for very noob question.
order_check.gh (81.9 KB)
Are you talking about your code or mine?
As far as I know, mine worked perfectly. Three days ago.
What about order_2025Jun27f.gh? Four days ago. 
yes the centroid of the polylines is perfect but the hexagons doesn’t match with that list. at this moment I have no idea how to match it. 
Unfortunately, I only vaguely recall how this code works. But if I understand your comments today, I sorted the points but not the hexagons
Sounds easy to resolve - four days ago. More difficult now. I count 26 GH files for other threads since then
Exactly the hexagons keep in disorder, but you got how to order the edges so maybe that could help for now. Thank you always…
Unfortunately, the edge labels don’t correspond to the sorted order and a quick fix failed due to recursive data stream…
This project has become a monster, dominating this thread since you restarted a thread that was a year old Any chance that a wizard admin (@wim?) can split this thread here? Other than the thread title, this project is not related to the year old code.
I think I’ve come up with a solution. The edge labels (numbers, white group) are still for the original sequence of hexagons but that doesn’t matter because they aren’t used. The import thing is that sorted hexagons now come from Seam at the end of the purple group. Try this:
order_2025Jul1b.gh (78.6 KB)
P.S. The 26 files I mentioned are only those I’ve posted. They don’t include files I’ve read.
Yes, Thanks!!! but at the end the order of the edgeswas not relevant to getting the pattern. I have not clear why but definitely with more logic.
I don’t fully understand your words as English is apparently not your native language?
In your first post about this five days ago, you said:
and hours later you said:
You must have had a reason? Can you test that? The purple group adjusts the seam to do it (though it currently assumes that all hexagons have same direction - counter-clockwise).
Where do you live? (time zone?)
Two things bothered me so I made some changes. I added a gray group at the top:
TEST: flip half of hexagons
And modified the purple group to use a circle as a guide to flip the hexagon curves so they always have the same direction. (they already did but just in case)
Then modified the white group to use the sorted points and sorted hexagons.
Tested. 
Hello again, not, English is not my native language I’m from México CDMX (GMT-6). And you? where dou you live?.
The first time I tested the pattern in hexagons I got something crazy at the end worked even If the hexagons not sorted.
As always definitions you provided works fine
At this point with this curves is possible get a kind of reciprocal structure ? or magaging the points? maybe I have to try with Ngon plugin.
I’ll keep trying.
pattern.gh (220.5 KB)
Oregon. GMT-8.
P.S. Just realized I forgot to post the latest GH file Added it now, above.
Have you seen this recent thread about a reciprocal structure?
I looked at the file you just posted and while some parts look familiar, I don’t know what you have done? If we were working together, we could use Hops or Data Output/Input to keep the code paths separate. But I think it’s best that I let you take it from here.
I’m not sold on reciprocal structures. Time for a new thread Link back to this one.
again thank you very much, first I’m going to try document myself and check some examples.
This is a pair of files, mine and yours, linked by Data Output / Data Input components in black groups. Hex_Out_2025Jul2a.gh (mine) must be opened first and any changes in that file will be transmitted to Hex_In_2025Jul2a.gh (yours) via a common file. In theory, I could revise mine and you could revise yours.
P.S. “In theory”, once the bugs are worked out! 
Re-posting renamed GH files.
Hex_Out_2025Jul2aa.gh (87.3 KB)
Hex_In_2025Jul2aa.gh (152.3 KB)
I had not idea how to use those components 
, I checked some Ngon files and the reciprocal components could works, I’ll be tesing.
They are simple and easy to understand (with some caveats).
An important idea for exchanging geometry is whether or not to keep the data tree organization by ‘V curves’ (V isocurves). As you know, the key to sorting the hexagons was to create 15 ‘V curves’ (light green group) spanning the surface and finding hexagon center points closest to each curve, then sorting them AlongCrv. That’s what the orange group is all about.
Except for ‘Srf’, all the data I am passing via Data Out (‘CntrPts’, ‘hexagons’, ‘hexPlanes’ and even ‘hexEdges’) has this data tree structure (15 branches).
Maybe that isn’t needed for what you are doing and is just extra work?
P.S. ‘CntrPts’ and ‘hexPlanes’ are redundant. They are the same point.
