one prim position of touch detection

Hiya,

being a silly man, I thought my best bet for a starter project in scripting would be a Go board. My priliminary looks over LSL suggested the simplest way to create the game would be to have the board skinned with a grid texture, and have one go stone shaped prim for every intersection. each if the pieces would be invisible by default. a touch would (setting aside for now how to keep track of whose touching, whose turn it is, etc.) cause the touched piece to ping the board and pieces through link. the legality and implications of the stone's placement would be sorted out, and the board would tell the stone to turn opaque, the color of the person touching it. The down side to this design would be the fact that a full Go board is a 19x19 grid, and, as such, my design would make for an object of 361 scripted prims, plus the board itself. This struck me as...potentialy laggy?

What I need is a way for a single prim to be able to detect where it's being touched, ie: clicked on. Is there perhaps a get function of some sort that can return a vector for where someone clicks?

Boogedy,

Technically you don't need scripts in your stones.

When linked properly you can determine the stones position by simply examining the link number returned on touch.

This also allows you to highlight or otherwise manipulate the touched prim in the linkset.

Exactly. Especially since you'll have stones on the grid, eventho invisible, those will be the prims touched, not the board underneath.

Unfortunately, there is no way to determine where a prim is being touched. Supposedly you can tell where a physical, movable prim is being grabbed and the direction it is being move with llDetectedGrab(), but I have yet to figure out a good way to make that work, and the function oft times returns rather strange values for child prims.

I'm just thinking out loud here... but I think it can be done with only 115 prims. That would be 1 prim for the board, 38 for grid selection (19x2), and 76 display pieces (using a modified 5-side scriptless XyText prim).

It would work via double-click to select the grid-space. Each row and column has an invisible bar running across/down. One bar is slightly raised above the other. The first click registers either a row or column, then swaps the bars so the other direction is raised. For example, the rows are raised... a player clicks row 15... all the row bars lower so that a column can be clicked... determining the crosspoint. The undo mechanism would be to reclick a bar outside of the grid where there is no overlap.

As for the display of pieces... you could use llSetLinkTexture() to set either OFF, BLACK, or WHITE. You have to calculate the row and face. For row 15(14)/column 9(, it'd be something like... (14(row) * 4(prims per row)) + 40(link of first display prim) + llFloor(8(col) / 5(faces per prim)) = 97(link number). Then calculate the face... 8(column) % 5(faces per prim) = 3.

So llSetLinkTexture(97, BLACK, 3).

Go boards are hard to design. My partner and I collaborated on one. You can find a vendor for our go board at the Go Center on Vineland (76,124). Or you can save the prims and just play at the Go Center (or at the Go Camp in Burning Life (Skylar) (100,131)). The Go board support 5x5, 9x9, 13x13, and 19x19 games, unlimited undo, computes captured stones, and scores the game at the end. It doesn't generate an SGF record of the game yet, but it will. We are going to open-source the scripts when we get around to it.

We tried many different schemes for controlling the stones and the one we settled on had the stones not linked to anything and communicating to the board via chat. We left the stones unlinked because of the 256-prim link limit. Having no scripts in the stones exposes you to the script delay in any of the llSetLinkFoo functions. Putting scripts in the stones but linking them to the board still slows things down. I think that the sims limit the amount of script time each object gets. To have a very responsive Go board you need to spread the scripts out amongst as many objects as you can.

There is a Go board that uses various tricks to get away with fewer than 361 prims, but the play is not as smooth as just clicking on a stone or position to play.

Maybe some day Linden Lab will let us paint prim faces with images from URLs instead of asset IDs and also tell us which face and where on the face a touch occured. But until then the best solution for playing Go is to have 361 prims.