Originally Posted by Innula Zenovka

So if and when Qarl's mesh deformer rolls out, it's not likely to be adopted by Phoenix?

Originally Posted by Chalice Yao

...
The FS team really, really needs to bury Phoenix and dedicate their resources to Firestorm. This whole splitting of devs back and forth between the two, along with the delays caused by double Q&A, is just horrible.

Originally Posted by Uffda Graycloud

I get the impression that they would really, really, REALLY love to do just that but aren't ready to deal with the howling that would follow as those who prefer (or can only run?) Phoenix get dropped outright and the (pardon) firestorm that the support folks would then get thrust upon them. It seems they were waiting for the Lab to break V1 things like they(LL) said, but never really did and let migration happen at whatever speed Linden Lab forced and let LL take any heat for it. Then LL went and didn't break anything or much (but kept saying 'Real Soon Now' for some time) and so Phoenix lived on, supposedly on borrowed time - and then mesh got backported to V1 viewers and merged into Phoenix... and thus Phoenix lives on and on and on... until the Lab really starts breaking V1 things.

Originally Posted by pancake

I can't speak for all Phoenix users, obviously, but I know a few who cling to it to the point of refusing to try anything else.

Originally Posted by Inhandra

That's where the "viewer = religion" phrase gets used.

Originally Posted by Uffda Graycloud

until the Lab really starts breaking V1 things.

Originally Posted by Siana Gearz

Due to Henri's work and Ansariel's port, there isn't much anything that LL could break, without breaking their newest viewer too, that would make it impossible for Phoenix to fix it in an update.

Originally Posted by Siana Gearz

It looks like they intend to keep Phoenix alive for a while yet.

Originally Posted by Kadah Coba

Well I be making a minimal effort for a while longer, I still can't stand to use FS for anything longer than testing.

Originally Posted by Kadah Coba

This was posted on SVC-4823 and I wanted to respond to a couple things, but Jira is not a forum.


Please don't misconstrue my questions, I'm only trying to understand the reasons are for needing these exceptions. I've seen both the argments made in this jira comment and the questions I'm posting here being said on both sides of this debate, so I would actually like to see responses from anyone to these.

Quote:
Originally Posted by Zanara Zenovka
I'm not really sure what's planned with this but changes to llRequestAgentData(uuid, DATA_ONLINE) can potentially break a lot of things.
(a) There are many legitimate uses of llRequestAgentData(uuid, DATA_ONLINE);
(b) There are already other methods for detecting online status without permission (giving inventory, sending IM, looking in group info, locating avatar in world, looking at avatar's home location on map.).
(c) Griefers and stalkers are going to do their thing regardless - we already have busy status, muting, land banning, which will still need to be used whether online status can be seen or not.
(d) To cripple a useful system feature in an attempt to control the aberrant social behaviour of a few individuals is unnecessary overkill.
(a) Legitimate uses of llRequestAgentData(uuid, DATA_ONLINE);

1. Postal delivery system that check online status before sending.
Essential for sending product updates to customers, items to event participants, rent notices to tenants, and more.
Otherwise inventory offers get lost to capping. Without this, only 10-20% of recipients will actually receive things sent via llGiveInventory.
I made Postmaster two years ago because I was sick of getting support calls for products that were 2 or 3 versions out of date, because increasing numbers of product updates were being lost to capped messages. Scripted products are always going to need updates as SL changes.
(Incidentally this also reduces a large number of llGiveInventory calls for items that will never be received. Recent throttling issues make this relevant.)

Quote:
Originally Posted by Zanara Zenovka
3. Vendors that only send gift deliveries when user is online (so it's received).
4. Gift-giving devices that wait til user is online (so it's received).

If changes for Direct Delivery work how LL has described it so far, this will be a non-issue soon.
It can also be said that this is a bug with llGiveInventory and should be fixed instead of it being standard practice to have to work around. Fixing the underlying issue is always a better option.
Better notification of received items when offline could be improved in the viewer.

Quote:
Originally Posted by Zanara Zenovka
5. Payment devices that wait til user is online (so payment is seen).

This is also something that could be improved in the viewer to notify the user when they login again that they were paid while offline.

Improving the offline notifications in the viewer when returning would be beneficial to everyone considering that the majority of things that send or give stuff to other people do not care if they are offline.

Quote:
Originally Posted by Zanara Zenovka
2. Using online status checking devices for business communication and customer support. Eg I check online status for:

• people I need to talk to
• people I need to pay money to (sure they could check transactions, but many don't know how to; this way they know they've been paid)
• people I need to give items to personally (with explanation/discussion)

Why should one person be allowed to ignore another user's privacy setting but no one should else should be allowed to ignore theirs?
If they are on your friend's list and have chosen to hide from you, why should that mean nothing?
If they are not on your friends list, but have decided to appear offline publicly, why is it important to ignore that?
Why is an this exceptions more important than intended meaning of "Only my friends and groups can see when I am online"?
Why is IMing the other person first to see if they are really online to receive something not an option? And if they happen to not be online, why is it not an option to leave a message (assuming it has not said the other person's IMs have been capped) asking them to reply when they are online again to recieve it?
Why is the web profile's PM feature not an option for any of these?

Quote:
Originally Posted by Zanara Zenovka
6. Mail dropboxes that forward NCs to managers or staff, but only if online (esp in the case of no-copy items)
7. Staff contact boards/online indicators (owner adds staff member UUID and their online status is shown).
Restricting llRequestAgentData(uuid, DATA_ONLINE); to owner's objects only (for example) would break all these above uses.
On top of this there are the owner-only uses, such as online indicators, and while making the function owner-only would not block this, you'd still have to explain to device users that they need it enabled (or not disabled) which is just another support chore to deal with.

And if they are managers of something that would need to be known to be online or not for being contacnted, why would they need to hide their online status publicly?
An owner check could cover #7 if they each person rezed a copy of their board (that would also make the script in the board very simple).
I would prefer to see llRequestAgentData's DATA_ONLINE restricted to only show public statuses, unless its on the owner, or has done an llGetPermissions, and if its not overly load bearing on the system, checking for friend relation and group membership as well.
Both of these cases (and many others) could be taken care of if there is a new llGetPermissions type.


Quote:
Originally Posted by Zanara Zenovka
Disclosure: I make several products that use llRequestAgentData(uuid, DATA_ONLINE). If it were removed I could certainly lose sales, but more importantly my everyday business experience, and that of my customers (who are also business people) would suddenly become a lot less efficient and much more time-consuming.
All this in order to block online status checking by griefers and stalkers, who can still get the same information in several other, slightly less convenient but equally effective, ways, and whose core activities do not depend on the feature anyway.

If this system is always checking llRequestAgentData for when they are online, what happens if they are never seen online during any checks over a long period of time? Does it just give up or send it anyway after some defined timeout?

And once DD is deployed and all given objects are auto-received in to an inbox, will that be better or worse than how it is now? Would there still be an issue if llGiveInventory no longer has the known offline lost on IM cap?

Originally Posted by Teeny Leviathan

Those Super Gays are as tough as a T-800 terminator and they are gay.

Originally Posted by Zanara Zenovka

So next time I want to disagree with something you've written and accuse you of anti-social intentions, I should post it in a random Jira? Or in a forum you don't read regularly?

Originally Posted by Uffda Graycloud

then mesh got backported to V1 viewers and merged into Phoenix... and thus Phoenix lives on and on and on

Originally Posted by Imnotgoing Sideways

The debug setting for Gender in SL (AvatarSex) is an unsigned 32bit integer value. Not a boolean. I'm still waiting to see what our other options will be. =^-^=

Originally Posted by Cristiano

Ok, I have to ask, WTF is this thread even about and why is it hundreds of posts? I am out of vodka so I don't feel like reading it to find out.

Originally Posted by Lutrai

Relating to the topic title: Now I keep getting IMs going "Are you online?" when I'm off because people are used to everyone hiding their true online status. I can't really blame them. I never used to get these because everyone had true online status enabled. Effectively, as someone who never hid his status, I have less privacy now than before.