llMessageAttachment();

We are going to need a feature for 1.7's HUD interface, that will work like llLinkMessage but only for use of attachments. So a clicked HUD prim could tell your other attachments what to do without the need of another laggy llListen. Something like llMessageAttachment(Pelvis,"Show"; *wink wink*. Being able to set up a hud that doesnt have to speak in a channel just to comunicate with other attachments would be great.

I started on a HUD interface for my avatar allready. and ive had to add another listen command to one of my attachments that listens to comands from the HUD. But llListen will only listen to either a object OR a person. not both. meaning i would need 2 llListens. Having one set as llListen(1,"Object Name","",""; will leave it open for ANY object by that name to give it commands. Which could cause problems.

It's basically a specialized version of object - object communication , then? I like the idea of being able to just say an attachment point rather than having to know a specific UUID.

/stamp. I like it

It's technically possible to transmit link messages across the agent, but it was disabled a long time ago since people were sitting on casino games and hacking them.

HAHAHA

llMessageAttachment(integer attachment, integer link, integer num, string str, key id)

Would raise link_message event in the prim(s) link in attachment. The recieved link number designating what prim the message was from in link_message would be the negative attachment number of the generating attachment.

If they tag "links" formed by sitting and skip them, then they can turn inter-attachment link messages back on...


PUH-LEEEEASE! The HUD elements NEED this!

I would very much like to have the HUD and the vehicle be able to communicate without listens, too. There's got to be aa way of doing the permissions to make everyone happy.

I would love to see attachments be able to intercommunicate as well. Been hacking all my control listens in preview so they can listen to my hud as well.

To resolve the issue of sit_hacking I would suggest an auto-granted permission on attach like anim but not auto-granted on sit. So that something that can send/receieve on sit would have to do a llRequestPermissions(key Agent, PERMISSION_ATTACH_MESSAGES)
This would protect current content and allow new vehicles/whatever to take advantage.

The thing I dont see an immediate solution for would be in a gaming system *cough*darklife*cough* where the Sword needs to tell the Backpack what powers it has without someone also attaching a prim to spew the info out so you can build your own +100/+100 Sword of MegaDamage.

Perhaps we need to go further and have something like:
llMessageAttached(integer linknum, integer num, string str, key id, integer pin)
where only attachments with the a pin set can share info if a non-0 pin is used, or if no pin is set can share freely.

Basically a link_message with a channel... hmm actually this could be useful for modular scripts that could be used in editable objects but protect data.
I like that even better... llMessageLinkedPin... would still communicate via the link_message event but only passed to items with the proper pin set. That way it protects data, doesn't fiddle with permissions and could be used for attached or unattached items.

Thoughts?
UU