|
|
|
This would definitely break a lot of perfectly legitimate content.
Example 1: I sell Rez-Faux, a packager/rezzer used for packaging and rezzing buildings that can't be linked into one link set. My customers have found that it can be useful to package a rez-faux package inside another to add optional features to their house. For example, you could make a house with a low-detail fireplace, and a subpackage that contains a higher-detail fireplace that can be used if the person has enough spare prims and is there to enjoy it. Example 2: My group has ambient physical devices floating around in our sim (Suffugium), such as cars that drive around on set courses, and police drones that float around and patrol the city. They're periodically rezzed by an object at their starting point. Your proposal would make it so that those cars and drones could not use any kind of visual effect that required rezzing objects. I can come up with more examples if you need them. Won't finish.
I'm always on the lookout for ideas that eliminate a lot of "bad" content, however all limitations on the Second Life feature set also block some of the "good" content and it is the ratio of bad/good eliminated that must be considered when evaluating such ideas. I think this very simple rule: "script rezzed objects cannot rez other objects" would have a very low bad/good ratio, since there is a very large amount of good content that relies on that working. BTW, there are already some limitations on script-rezzed objects however they are mostly rate-based, and the limitations only kick in when a great many rezzes are happening very fast. The challenge is to come up with rules that single out the bad stuff while letting the good stuff still work. Okay then, instead of a single bit use a 2 or 3 bit value that keeps track of the replication depth and stop it after a few ("hide" the depth tracking bit inside the on_rez() event?). Even with the examples provided I don't see any reason why you'd need more than 2 levels of depth... maybe 3 at most. So many different types of TOS-violating and gray area scripts use the ability to reproduce to infinity and so few truly legitimate things use more than just 1 or 2 levels. A little creativity can go a long way here - maybe only impose the limit for no payment info on file avatars or reserve infinite replication for premium members.
I don't mean to sound totally pessimistic, but the way this was shot down makes me wonder if there are any plans to curb grey goo (now with added ddos) attacks at all. I know it's a difficult problem to solve, but someone has to. Every one of the tens of thousands of people affected is counting on it... FYI, Andrew Linden was behind the Grey Goo Fence, which was implemented a couple of years back after a particularly bad series of grid bombs. Since then, well... attacks that take the entire grid down seem to be a thing of the past. He discussed the fence extensively with the community between iterations in order to avoid breaking content.
The thing to remember is that griefers are humans, and some of them are pretty ingenious at that. They often find ways around software-enforced grey goo rules. If you had to break some content to implement those rules, then the net result is that you've broken content and have nothing to show for it. An example of "legit" infinite replication would be spawning fish (or your favorite a-life experiment).
An example of "legit" self-replication (where an object rezzes an asset, then gives that asset to the rezzed version) is a branching tree that stops itself after some number of branch splits. Unfortunately the grey goo fence (GGF) cannot distinguish the difference between this type of content and an unbounded version so it cracks down on both. You have to grow your replication tree rather slowly to avoid the GGF. Turns out, there is already hidden rez-depth history stored per object which is used for feedback into the GGF but the logic is tuned to only increment the rez-depth history under certain circumstances, specifically fast rezzing. I haven't heard about much "legit" content running afowl of this rez-depth info, but some probably is – it just shows up in when the GGF clamps down. As Mbrb mentions, a number of legitimate weapons rez an object (a grenade, missile, or bullet) that then rezzes an explosion or other damage-enabled items. However, limiting it so that an object can only rez 1 object would still break a lot of content there that rezzes several objects.
One example is the Black Ops White Phosphorus grenades. These are really creative and cool items, where the grenade launcher rezzes a physical grenade fired out at a set velocity. When it detonates, it rezzes several little balls that have fire particle effects, each one is scripted to do continuous SL Damage to any avatar who walks over them in a Damage-Enabled zone (they're otherwise fairly harmless effects in a non-combat area). Similarly, we have a fragmentation ("frag") grenade that detonates and rezzes a number of physical shrapnel prims that go flying out, each scripted to do 40% damage over Damage-enabled land (can also be used against some collision-based HUD combat systems if allowed by sim admins). Similarly, limiting replication depth to only a few levels of depth would still break the teleporters mentioned above. I'm sure that there are a number of other self-cleaning mechanisms used that might be broken by this, where a creator intends for a prim to rez a copy of itself and then delete after being used. Also, remember that because an object is limited in the distance radius that it can rez another object, having an object rez one object, which then WarpPoses/MoveToTargets to another place and then rezzes another object is quite common. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Normal
Anti-replication: Objects rezzed with llRezObject() can't use llRezObject()
That is, you sit on the teleporter, it rezzes a duplicate in its place, wisks you to the destination and then deletes itself. If this were implemented only the first one would work, the duplicates would not be able rez further duplicates.