is there an alternative to llListen for unlinked objects?

i have 2 objects there are close together but not linked. I heard that many listen script will lagg a sim, and at the moment, i would have 12 listen scripts minimum, and im looking for an aalternative that would be easier on the sim.

12 listen scripts? Or one listen script with 12 conditionals (i.e. if msg == "phrase1" do this else if msg == "phrase2" do that).

Keep in mind you can also just load up a list with your phrases and do a search through it to avoid endless conditional chains.

I'm also getting dubious of the increasingly accepted "fact" that listens are bad things. Sure if anything is used too much and badly that's not good, but overall llListen is the mechanism we are given to do these sorts of thing, so I shan't be afeared of using it.

Any hard data on llListen to corroborate the "they lag the sim bad" thing? I mean hard data like developer numbers.

Well, if possible, you could reduce those 12 listens to one per object. Instead of having a listen where the command is in the llListen(0,"",NULL_KEY,"lalalala" command, put the commands in if statements inside the listen() call. You can use just one listen that way, and filter through that. You can also filter by user and name 'n such, if that's why you have so many listens.

it is 1 listen per object, but i will have 12 object. And have 12 or 3 conditions to each one.

Well then if they're unlinked, you have no alternatives. Simple as that.

Don't feel so bad. I have 60+ objects in a sim, each heavily scripted with something like two listens each. Doesn't seem to impact the sim too badly.

Mole, it really does though, one of the private island owners is doing some really interesting testing right now on sim performance vs various issues.

Listens are the worst.

I saw that, His Grace. Pretty cool stuff. I just skimmed through it. Thats why i was asking if there was an alternative

There is a lot of alternatives; eg: (there's plenty more)

- Poll llKey2Name (I generally use this myself as preffered method, especially long distance)
- Sensor + llDetectedName
- Email

-Adam

Listens effecting sim perf is old news...a long time ago Cory (I think) published a thread that showed the impact of a variety of functions to sim perf, and if I remember, Listens were up there. I'd be curious about threshhold info, that sort of thing.

Something people forget is that listeners don't have to be left running 24/7. They can be added and removed dynamically. For instance, a short sensor, when detecting an AV, can move to a state with active listeners. When the action is done or the AV moves away, the listeners can be dumped on a state change, or just outright removed. If coders only engage listeners when required, and clean them up when not, I think a lot of the problems people suspect are occurring due to them would go away.

Situationally, yes, sensors, polling or emails can be viewed as alternatives, but sensors give you no way to pass in data to the sensed object directly (which would be cool)..you can get data about the object, but not give data to it, and email of course involves using the email system and adds several seconds, up to 30 many say, to the action. Overall, for non-linked object communication, and imho due to the molasses performance of link message even linked objects, llListen rules supreme. My mHUDS are the perfect example; using linked messages, they were way too slow. I switched to listens and zowie the perf went through the roof.

What we need to do is push LL to lower the impact of scripts on sims ;p

Yes, I know listens are bad, but the sim is routinely in the 2000's for FPS, and generally anything higher than 750 is way too perfect.

Besides, there's simply no alternative whatsoever.

Sounds like we need to propose something in Feature Suggestions then.

What kind of communication mechanism would be the absolute bee's knees for scripting composite systems that need various unlinked parts to communicate with each other or with a plot controller?

if possible use a non-standard channel. (anything other than channel 0)

I'd propose a llMessageUnlinked function that works in exactly the same way as llMessageLinked, but takes a key rather than a link num:

llMessageLinked(key object, integer num, string str, key id)

That, combined with a new event handler (unlinked_message maybe which passes the sender key) would do whatever I need.

Yes, that seems reasonable.

Mind you, it wouldn't need to be called llMessageUnlinked, since if it's addressed by key then it would apply to any object as target, including those that are linked to the sending prim. Sounds like an llMessageObject() then.

We might need more options on the messaging listener though, to restrict received messaging events to certain categories like MSG_ONLY_FROM_KEY, MSG_ONLY_FROM_OWNERS_OBJECTS, MSG_ONLY_FROM_OWNERS_GROUPS, and possibly others.

Interesting idea. Maybe require the use of the PIN as a security mechanism? Many current scripts assume that only messages from within the current object will be sent, so some sort of default security would be needed.

Xylor

Hm, I would think it would need a new event, and not to be pushed to the existing link_message event for that exact reason Xylor.

Also the parameter signature is a little different:

unlinked_message(key sender, int num, string mes, key id)

(erg we can come up with a better name right??)

It's called "Instant Message" and we've been asking for it for ages.

That said, in the case I'm using llListens, an instant message to objects feature wouldn't help in the slightest. I need to be able to fly up to a swarm of fireflies and interact with them without having to figure out keys, or work through another object.

Good point, Ama ^_~

Xylor