Phil Deakins
-
Posts
13,494 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Phil Deakins
-
-
From my experience of going to clubs with live eneteratinment, it's the entertainer's group that sends the spam invites, and it's done by a person who is too lazy to first ask if you'd like to join the group. The fact that I'm there (presumably) enjoying the entertainment is in no way indicative of my desire to 'sign up' to the person. I consider it spam. It may or may not be considered ok in general, because it's on the land of someone who is employing the entertainer, but to my way of thinking it's unsolicited and it's spam - and it annoys me.
The time it takes to say no is irrelevant. It takes next to no time at all to delete spam emails but they are still spam, and a blight.
-
The idea of offering group invitations to people in stores, without asking first and however much time is given for them to acclimate, is spam, imo. It might be acceptable if the invites were sent to actual customers - those who actually buy something - but going to a store is no indication at all that the person is in any way interested in becoming (almost) part of it, which joining a group is. I.e. a visitor may look round, decide there's nothing they want from there, and leave. An auto-invitation in such circumstances is, imo, unsolicted and, therefore, spam.
-
Personally, I don't differenciate between so-called 'expected' group invites, in clubs for instance, and those that arrive when I'm nowhere near anything. I view them both spam. In clubs, the 'workers' do have the opportunity to ask if I want to join a group before sending an invite. If they did that, it wouldn't be spam. Stores that don't have workers there at the time just need to put a sign up - 'click here to join the store's group'.
-
Luc Starsider wrote:Ah, right! I didn't read your post too well.
So, this is the 'Don't worry. We're building more' part of the message. Two weeks is a long time to let customers wait. Perhaps the Moles are on strike? Everybody has been let go, and there's no one left to start the auto rezzer?@Peter. You might very well be right. I don't blame LL for trying to get more customers, and I hope they manage. I'm not sure I think the customer they're after is the 'right' type... Also, contrary to what I have a feeling LL thinks,trying to attract new customers does not mean you have to abandon and forget the existing customers.- Luc -
I completely agree with that. Posting necessary information on Twitter is fine but it should always also be posted where the users are - here or in the blog. Posting necessary information exclusively on Twitter is a really idiotic thing to do, and it reveals something (really negative) about the person who decided to do it that way - Rodvik, wasn't it?
-
lol, Marigold. It wasn't me, of course, but it's good to know that I've not been the only Ruth with a beard
-
Just lucky lol
-
The screenshot says, "You can also follow @SecondLife on Twitter for updates." How idiotic is that?
-
Thank you, Marigold. I've read the jira you linked to and it's happening to a number of people. What I didn't think to notice when it happens, and the jira mentioned it a number of times, was the precise location where there message tells me the object tried to rez. It sounds like the system thinks it's trying to rez on another parcel. I'll take note from now on.
-
It seems like it's a server bug then.
And where's your picture? I want it back
-
I'm using LL's current V3 and it sometimes prevents me from rezzing objects on my own (group) land, telling me that the land-owner doesn't allow it. It's wrong, of course. The objects are my own creations and I naturally have full perms.
When it happens, it seems like there's a spot where I simply can't rez anything for that (wrong) reason. If I do it a few meters away, it rezzes fine. Another time, I don't have a problem in the same spot. It's not just one sport. It can happen anywhere on my land.
Has anyone else come across this oddity?
-
I never realised that Ruth was quite so pretty
As far as I know, it's been years since I was Ruthed. I saw myself fine but others saw me with boobs - and a beard!
-
You're right - I won't turn it into a scripting discussion. I'll just say...
Good idea about centralising the 'book-keeping'. Some of it is already centralised (CHANGED_LINK, for instance), but some significant chunks of it could also be centralised - adjustment stuff, for instance.
And what you mentioned in your last paragraph is also right - it would be overkill for my use of the system.
-
Qie Niangao wrote:Speaking of lag, I want to echo Phil's question, re: MLPV2 supposedly being script-heavy. It contains a lot of scripts, that's true, but they're pretty efficient. I've monitored some sim statistics in my time, and I've never seen a product based on MLP contributing much to script load. (I wish I could say the same for another "sitter" product that I won't name here.) That said, the nPose approach has a slight advantage over MLP in that it doesn't use rezzed poseballs; it still uses a separate script for each sitter in order to be able to keep animating them, but those scripts can be simpler, not needing to rez poseballs and communicate where they should go.
There was a thread here recently about animation systems that don't use poseballs. It piqued my interest so I wrote one, and it's in some of my beds now. Nobody mentioned that nPose doesn't use poseballs or, if it's a free system, I could have saved the time
However, it did give me something interesting to do, and still does, so it's been well worth doing.My system also uses a script for each possible user but each of those scripts uses 12.3k of memory so they're not exactly super-lightweight in terms of memory usage, but they aren't very active so they're not laggy. I've no idea how 12.3k compares to other systems. What such systems don't do, of course, is perpetually listen like poseball systems do, so they gain a bit in that respect.
-
Pussycat Catnap wrote:MLPV2 burns up a lot of script usage. Intan doesn't. That's key - especially for a busy social venue.
Do you know for sure that MLPV2 "burns up a lot of script usage"? I haven't seen the system.
The reason I ask is because it's a development of the MLP system, which was limitied to 16k per script when it was written (pre-mono), so every script in it was allocated 16k of memory. Since it's developed from MLP, it probably still uses the same number of scripts, and maybe more. But, if the scripts have been changed to mono, they only use the memory they actually use rather than the fixed amount per script regardless of how small the code in the script is. Also, scripts may have been amalgomated.
Script impact is more important, and the number of scripts is relatively unimportant. It isn't the number of scripts that matter - it's the actual memory that's used by the scripts in operation that matters - specifically how much 'work' each script is doing. For instance, a new script that says "Hello avatar!" is a tiny programme that requires a tiny amount of memory. If it's compiled in LSL (LSO, but the compile options say LSL) it will occupy 16k of memory, which is massive compared to what it actually uses. Almost all of the 16k won't be used so it won't impact on anything. If it's compiled in mono, it will only use the tiny amount of memory that it needs. Either way, the scripts will only actually use the amount of memory that they need.
The script usage numbers reported by the V2/3 and Phoenix viewers are wrong. They only report the maximum that a script can use. They don't report what the script actually uses, so it's impossible to ascertain the impact of a script from those numbers. For instance, the new script that says "Hello Avatar!" will be reported as using 16k of memory if it's compiled in LSL or 64k of memory if it's compiled in mono (the default). But the script will never actually use anywhere near either of those figures. 16k will be allocated to it in LSL, but it will only use a very tiny amount of that, and, if it's compiled in mono, it will be allocated the tiny amount of memory that it actually needs. It's what a script actually uses, and especially how much 'work' it does, that impacts on things, and the numbers reported in the V2/3 and Phoenix viewers are wrong because they don't have the correct numbers.
You can have a load of tiny scripts in an object, all compiled in mono, and the combined memory they'll use will be tiny. If they aren't doing very much, they'll have negligable impact on anything. So put 10 "Hello avatar!" scripts (complied in the default mono) into a prim and check its memory usage. It will show 640k. But, combined, they will actually use just a few k, and only a few k of memory will be allocated to them. And since they don't do very much, their combined impact will be negligable - and it's that impact that matters.
So, to decide that a system "burn up a lot of script usage" a lot more needs to be known about it than just the maximum amount of memory that its scripts could use, and all we can see is that maximum.
The "key", therefore, is what 'work' an object's scripts do over time, and not the amount of memory that's allocated to them, or the number of them.
-
What Qie said. Plus it says nothing about users not being allowed to "circumvent the permissions system".
So we have the answer. There is nothing in the ToS about "circumventing the permissions system", so there's nothing that could be open to interpretation, or "ambiguous" as someone put it, and that particular discussion was wholly unnecessary. That's it.
There ought to be a rule somewhere against circumventing the permissions on other people's objects but there's nothing at all against it in the ToS.
-
Anaiya Arnold wrote:@Qie: I've never known simply discussing the clarity of a document to be described as hysteria before, but if you wish to get all over excited and way over react to a mere suggestion that something might be ambiguous, it's your heart pressure level, not mine.
I would seriously like to see the part of the ToS that you say might be ambiguous. I couldn't find any form of words that were concerned with circumventing the permissions system.The permissions system does get mentioned a few times but there's nothing about circumventing it. You may have read something somewhere, but it's not in the ToS, and if it's not there then the argument that it may be against the ToS is a non-starter.
-
One more thing. Neither you nor a script can terraform land beyond the land's limits. If the land is already at its lower limit, it can't be persuaded to go any lower.
-
PeachJubilee wrote:Innula Zenovka wrote:I have to say I read the bit about circumventing the permissions system as being directed at stopping people changing the terms of the licence the object's creator has granted them to use it, but there's only one way to find out -- if someone thinks a no-copy, no-mod, no transfer item is against ToS then simply AR it and see what, if anything, happens.
I would read it exactly the same way if the ability to set an item to no copy and no transfer were available from the permissions section of the edit menu.Your thinking is that, because LL made it impossible to set an object in the Edit box with no perms at all, doing it another way is "circumeventing the permissions" and is, therefore, against the ToS. I say you are wrong, and I'll use your own thinking to show it.
As has been pointed out, LL made things so that we can make objects that have no permissions at all. Therefore, doing it is not circumventing the permissions because LL gave us the means to do it, so it's not against the bit of the ToS that you think it's against.
I'll say it again. Circumventing the permissions system means getting around the permissions set on other people's objects. It has nothing to do with our own creations.
ETA:
One more thing. I have searched the ToS on the words "permission" and "circumvent". "Circumvent" isn't used anywhere and I found nothing that suggests what you say the ToS says. I think there should be something there that's relevant but I can't find anything. You wrote, "It's against the TOS to circumvent the perms system". Perhaps you would copy-paste the bit of the ToS you are thinking of.
-
Scheduled means planned in advance. They could schedule it to occur in 5 minutes time
I assume it's something that they realised they'd have to do urgently, rather than the normal scheduled maintenance. Perhaps it's a result of the unscheduled maintenances that we've had lately; i.e. summat's badly wrong and needs to be dealt with urgently.
-
That's what I took it to mean too.
-
I've recently been forced into using LL's V3 viewer - the one your screenshot is of. I've thought that the buttons on the bottom bar could do with being smaller when they only display icons. I see that you've done exactly that. How did you do it?
ETA: Cancel that question. Your post says it's Firestorm. I've never seen Firestorm so I didn't recognise it.
-
Any circumventing of the perms system that's against the ToS is concerned with bypassing or changing the perms of another person's items. It's nothing to do with setting perms on your own items.
Setting perms to no-copy, no-mod and no-trans is perfectly in keeping with the ToS. It's not for any user to say that, "if LL had wanted... etc.". Imo, LL made the perms in the Edit box the way they did simply because they thought that would be how they were wanted and, on the whole, they were right.
I'd still like to know exactly what the item is but I suppose, unless the OP says what it is, I'm not going to know.
A general point:
Selling traffic-gaming systems, and owning them, is not against the ToS. It's the gaming of traffic (actually doing it) that's against the ToS.
-
I don't doubt your experience for a second, but I'm puzzled as to how you not having anything visible caused you to be what sounded like lag-free. Your viewer still has to download all the other avs, their movements, etc. etc., just like it has to when you're clothed.
-
Rosemaery Lorefield wrote:I haven't read ahead, but in case no one else explained what the product is, it's a sploder ball. It's against TOS, maker had a work around, but got called out, changed his product and now users of the (against TOS) product are pissed.
Are you sure it's a sploder?
I'd just read all the OP's posts before I saw you'd posted, and there's no indication as to what the item is. There's a clue for anyone who knows the item well enough. He said that the creator had stopped the original version that he bought from working, and had forced users to either upgrade or call it a day with the product. Anyone who is familiar with the product, or has read about it, would probably recognise that history.
Facebook
Instagram
Twitter
YouTube
Flickr
Latest V3 oddity (for me)
in Second Life Viewer
Posted
I've been waiting to see the error message again before I add to the jira but I don't rez things all that often. However, it just happened again:-
[05:23] Second Life: Can't rez object at { 152.644, 134.012, 255.081 } because the owner of this land does not allow it. Use the land tool to see land ownership.
[05:23] Second Life: Can't rez object at { 153.394, 130.847, 255.081 } because the owner of this land does not allow it. Use the land tool to see land ownership.
[05:23] Second Life: Can't rez object at { 149.871, 132.249, 255.081 } because the owner of this land does not allow it. Use the land tool to see land ownership.
[05:23] Second Life: Can't rez object at { 153.215, 134.596, 255.081 } because the owner of this land does not allow it. Use the land tool to see land ownership.
[05:23] Second Life: Can't rez object at { 159.92, 130.923, 255.081 } because the owner of this land does not allow it. Use the land tool to see land ownership.
[05:23] Second Life: Can't rez object at { 153.18, 130.614, 253.71 } because the owner of this land does not allow it. Use the land tool to see land ownership.
I was trying to rez a bed inside my store, which is ~250m in the air. Each of those failures shows the Y co-ordinates well outside the north edge of my land, which ends at 128m, and yet I was pointing at the floor inside the store - a few meters south of those Y co-ordinates (~124m).
Now I'm off to add to the jira.