Kyrah Abattoir
-
Posts
2,296 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Kyrah Abattoir
-
-
Thing is few large and powerful land owners are not such a great deal for Linden Lab:
- From a logistical standpoint, yeah fewer customers is better but...
- All of them generally pay their tier at the highest possible discount since they are at the very least owning a whole region worth of land.
- When you own dozens of regions, you have a lot more power and leverage than a dozen of people with 512 sqm plots.
- Anytime one of them decides to pack up, it hurts, a LOT. When a 512sqm user decides to pack up the effect is negligible at best.
One region 100% occupied with base premium users nets Linden Lab from 384$ to 608$ a month (assuming 1024sqm plots).
One mainland region owned by a land baron nets Linden Labs from 165$ to 181$ assuming group bonus and a fully tiered up land owner.
Even at 50% occupancy small land owners are still more profitable.
-
3 hours ago, Shnurui Troughton said:
So far, i see good news and not so good news.
As a furry avatar maker, i will have access to every furry body skin, ever made, for the core sl body. That is to say, my customers would.
The down side is I'm not seeing an option to bake on the left arm/right arm separate. This wouldn't require a uv change, just the option to bake the upper_body map twice.
-WITHOUT LOOKING AT THE CODING- it appears this could be picked up the same way the hair mapping does, -I'M MOST LIKELY WRONG ABOUT THAT-
This assuredly comes from the fact that they never gave the left and right arms a separate material, let alone a distinct uv map.I doubt they are planning on giving us "more" baked textures per avatar.
An alternative solution could be, for arm differenciation, to use a "non" bake on mesh texture for the second arm.
But that would negate the benefits of piggybacking on legacy texture layers.
-
4 hours ago, Blush Bravin said:
Did you read the whole thread? Were you around when the Omega system first appeared on the grid? In case you weren't, a short run down: There was a whole line of thought going around that because someone had system clothing they then had the right to use the UUIDs (obtained from the developer menu) of the clothing layers they owned to make appliers. Whether that line of thought was correct or not is not the issue. The problem was that those UUIDs got passed between friends and then even wider circles. It's one thing to have to deal with copybotters and ripping of textures using third party software. We all know that happens and honestly there's not much we can do about it except to file DMCAs. But it's another situation when people have easy access to UUID numbers inside the viewer itself and then begin passing those UUIDs around.
I've been making content in SL for what, 13 years now? This is not news.
This is the same discussions we had when libopenmetaverse came out, when the client was opensourced, and when the first clients modified to bypass permissions came to be.
-
So the issue is that the layer is actively textured hm. Interesting.
-
Use a body without alpha layers maybe? Does the creator provide a with and without version?
-
I don't really see what the obsession with UUIDs is when ripping textures would be much more convenient for the perp.
-
1 hour ago, Rolig Loon said:
No. The other bits of advice in this post are good, but this particular bit of information is false. Scripts are far from the #2 reason why regions may slow to a crawl. Server resources are allocated in such a way that all other demands are addressed before scripts. Scripts have the lowest priority on server time. As a result, avatars, physics, communication, and all other region operations can lag scripts, not the other way around. Scripts can indeed lag each other when server resources have been drawn down by other demands and there is no spare time left even for scripts. Also, scripted objects can cause lag, for example by rezzing objects or by managing vehicles or physical objects, but in those cases it is the act of rezzing and the physical objects themselves that are using server resources. There is no excuse for sloppy or inefficient scripting, which is why most of the other advice is valuable, but region lag is not the primary reason for writing tight, efficient scripts.
Allright i might have made a slight hyperbole, I did mention avatars as number one, and laggy objects rarely happen without scripts.
I've seen regions that had performance problems due to an over abundance of individual trees that each had their own script/menu, while they don't do anything most of the time they still eat a sizeable amount of memory and event processing by just sitting there.
-
Scripts don't run for free, the N°1 reason regions slow down to a croawl (after simply too many avatars) is too many scripts.
- A single script can do a lot of small tasks quite competently and efficiently, try to avoid using multiple scripts for a task that can be performed by a single one.
- Avoid using multiple scripts because "it makes things convenient for you", script count adds up very quickly, especially if you are making parcel decorations, try to work with efficiency in mind.
- If you are a seasoned programmer coming from more advanced languages or object oriented programming, resist falling into your habits, the LSL/Mono compilers are crude and simple, You have to do the micro optimizations yourself, possibly at the expense of readability.
- Learn to use llSetLinkPrimitiveParamsFast() for all your visual changes and only call it when the changes you make are significant (no 0.0001 changes in transparency/color for instance.)
- Keep a tight leash on how many listeners you use and close them (llListenRemove/llListenControl) as soon as you have no use for them anymore.
- Cache data that you rely on frequently rather than requesting it constantly.
-
1
-
On 4/20/2018 at 2:55 AM, Rolig Loon said:
Hi, again.
Ruthven has shown you the way to handle one tree. The way to handle 50+ trees (assuming that they are identical) is to script one tree and copy it 50+ times. That's a lot more efficient than loading scripts into 50+ trees.
There's no way to script 50+ trees at once. With a little bit of planning, though, you could change the leaf texture on every single tree with one command. You would need to write your basic tree script to listen for a command from a master script that sends it the UUID of a new texture and then substitutes the new one for whatever was there before. It would mean thinking through the logic carefully, but wouldn't actually be all that hard. Once you had all the trees scripted, then you could change the entire forest from spring leaves to summer ones or moth-eaten ones or fanciful fairyland ones with the touch of a button on your master scripted object. Might be kind of fun.
An even better way that doesn't make the region beg for mercy would be to use a root prim and a single script driving every single tree's animation as a single, large, linkset.
-
System layers are a convenience tho, personally I routinely use my system body as a "glue" for mix and matching parts, so I definitely see the value in having them provided.
-
It's very nice, but as with all those features it is presented on its own, in an existencial "vacuum". The problem is typically when you try to integrate those within a complex environment that needs processing power for "other things".
-
36 minutes ago, ChinRey said:
That is a problem, yes. Unfortunately it is even easier to rip the UUIDs from applier clothing for mesh bodies.
Or to put it this way: with bakes on mesh, it should be possible to upgrade the texture UUID security for applier clothing to the same level as system clothing has now.
If we can call that "upgrading" yeah. I wish we could shake this delusion that there is some way to protect art assets while still displaying them.
In the realm of computer, read right == copy right.
-
2
-
-
On 5/1/2018 at 4:00 PM, Blush Bravin said:
I stopped including system layers with my appliers because it was brought to my attention how easy it is to rip the UUID numbers of any worn system layer. So my question is if this project goes forward with an applier system in place what safeguards will there be to prevent use of a UUID# without actually owning the texture to make appliers?
Ironically system layers are (only slightly) more troublesome to get out than anything on an actual object.
Congratulations on providing a worse service to your customers for no gain.
This is the wrong battle, you can't prevent people from ripping any assets from SL anymore than you can prevent it in any other game/game-like application. You should focus on providing good support to your customers and witholding system layers doesn't qualify for "good support".
-
8
-
-
Yeah that's what I mean. Actualy percentages should be mandatory.
-
1
-
2
-
-
2 minutes ago, angeoco said:
Most products will work without any reliance on the supplier, but the difference with TMP is that their products depend on communicating with TMP servers, which have to be kept running 24/7, and that costs money. According to comments in this forum, they seem to have lost interest in updating or supporting their products, and their market share is constantly declining. They are not going to keep their servers going when they are losing money with no prospect of recovery.
IF they where good people they would make one last update that removes the 3rd party server reliance.
-
3
-
-
The unfortunate reality of purchasing "software as service".
-
2
-
-
Just now, CoffeeDujour said:
.. and magic cards are also gambling and should be covered too.
I still don't get how collectible card games get away with not publishing odds, unless it's actually posted somewhere?
-
1
-
-
On 3/17/2018 at 2:09 PM, angeoco said:
TMP have had plenty of time to issue a Bento update, but it hasn't happened. Many people here are of the opinion that TMP have given up any development or support and will probably close soon.
Why would they ever close? A lot of old creators have stopped all involvement in SL but are still selling and probably will until SL implode.
-
"Applier layers" Are essentially a second, third (or more) copy of your mesh body slightly offset from the previous one, so while they are very close to the body they still occupy some amount of physical space. It's a terrible (and irresponsible) solution some mesh body creator are using to solve a problem that hopefully bake on mesh will render obsolete.
-
To me the biggest issue with gachas is that the machines do not state what the odds are, that in itself is basically dishonest.
-
3
-
-
Soo, I figured I'd step in (probably a terrible idea, considering the audience), but where I live, the criterias of whether something is child pornography or not, it's not just the proportions, or just the signs of puberty, or just the demeanor, it's a whole set of things, but more importantly, it is left to the apreciation of a judge in a court of law.
Not you, or me, and especially not bat**bleep** insane ranting oldbies.
-
For me it's like the weird frownie rabbit face, it's what the brazilians that squat my rooftop in sl wear.
-
-
But at the same time SL cannot exist forever, it will eventually disappear. At least we know linden labs is working on a replacement.
Ruthven has shown you the way to handle one tree. The way to handle 50+ trees (assuming that they are identical) is to script one tree and copy it 50+ times. That's a lot more efficient than loading scripts into 50+ trees.
Facebook
Instagram
Twitter
YouTube
Flickr
Bakes on Mesh Feedback Thread
in Bakes on Mesh
Posted
You seem to be overly concerned about what paying customers would do with your product. As I said those who don't intent to pay in the first place aren't gonna be stopped by this fix, so the people this will penalize are customers trying to exercise fair use.