crash: sending a tp offer to more than one person crashes the viewer

[Lance Corrimal]

When you send a TP offer to more than one person at once, the viewer crashes with this as the last lines in the log file:

{{{ 2011-09-19T20:53:43Z llmessage/lltemplatemessagebuilder.cpp(308) : error 2011-09-19T20:53:43Z ERROR: addData: Message not a variable in block TargetData of StartLure }}} Repro:

• select more than one friend from your friends list
• click the teleport button
• the viewer freezes

Reproduceable in RestrainedLove viewer v2.04.00.00 and RestrainedLove viewer v2.07.03.03 Does not happen in original SL 3.0.0

I think anything that freezes or crashes the viewer through normal/common use of mainstream features should be rated blocker.

[Marine Kelley]

Thanks for the bug report. This has been a long-standing bug (I remember someone told me about it long ago) and I'll look into it soon, however it should not be a blocker because "mass-tping" is not something you use everyday, and leads to a result that you can achieve through other ways (namely, tping people one by one). I reckon freezing on this kinda sucks, though :)

[Lance Corrimal]

well, i rated it blocker based on the original priorities on the LL jira...

...on the other hand, there blocker usually means "we'll fix that in a year or two", and *can* mean "expected behaviour" 0.o

still, a reproduceable "crashes the viewer every time" is *very* major.

[Marine Kelley]

Yes, LL's JIRA states that a showstopper is a bug that prevents you from using SL : a sudden crash (either random or while doing a common task), not being able to log in at all, or having crippling framerates qualify as showstopper. A critical is a bug that requires all the attention of the devs and must be fixed asap because it really ruins the fun and potentially LL's business in the long run. While a major is a bug that is annoying but that can be overcome (of course that doesn't mean it shouldn't be taken care of !).

And in fact, I personally believe that this bug should be "only" major precisely because it is reproduceable. It would be critical if it were random.

I'll write a few guidelines about how to rate a bug soon, it is the subject of endless debates, including in the companies I used to work at :)

[Marine Kelley]

Fixed in 2.7.3.3

Note to self : When you add a feature, test it. Otherwise you are 100% sure it will be a bug instead.

[Lance Corrimal]

yup, can confirm this fixed.

[Lance Corrimal]

actually the fix seems to have a sideeffect.

lets assume 2 avies, A and B A wears an opencollar where B is listed as owner, and therefor listed explicitely in all kind of recvim: and sendim: exceptions, which if I'm not wrong mean that A will always receive IM from B no matter what else is set. Also, opencollar sets tplure: and accepttp: exceptions with the owner uuid.

now, A sends a TP to B, and B gets it with (Hidden) instead of the location where A is ?????

This does not happen / works normally as soon as A either relogs to a viewer without that fix, or takes off the collar and waits for the RLV settings to be cleared by the garbage collector...

Shouldn't the dom *always* see the subs location?

[Lance Corrimal]

possible fix in http://dolphinsource.eregion.de/dolphinviewer3/changeset/d92e7d54f086

[Lance Corrimal]

darn. that fix does not build properly. needs more work.

[Marine Kelley]

From what I saw in the code, you can't send a different TP message to each friend you are trying to TP. They all get the same message. That's why if you are prevented from IMing even just one of them, or have your location hidden from you, every friend will receive a "Hidden" message instead of the original one. That's not a bug to me, but a limitation of how the initial codebase works.

However if you do have a fix for that, I'm all for integrating it :)

[Lance Corrimal]

the avatar that I'm experiencing this on is not prevented from sending IM to anyone at all, but has the avatar who is listed as the collar owner in a sendim: exception...

in this case there shouldn't be "(Hidden)", shouldn't it?

Anyway, apply http://dolphinsource.eregion.de/dolphinviewer3/changeset/c19d57c288db on top of my previous changeset and the tp invite works the way it should as far as i can tell :)

you know how to use the transplant extension for hg?

[Lance Corrimal]

hum. thinking of it, I think the code needs more work... right now it does *not* check if any one avatar in a multiple selection is disallowed from being sent IMs... grr. sounds that needs its own loop 0.o

[Lance Corrimal]

ok I have a working fix now.

[Marine Kelley]

Fixed in 2.7.4. Thanks !