No-mod Object = No remove scripts?

And yes this is circular logic but if making it a feature that was easy to use would result in it showing up in areas where it wouldn't belong. The hastle involved in implementing what i suggest is why i suggest it. There should be a price for using security and if you don't want to pay it then you don't get it. Nobody benifits from a locked down product except those collecting the money.

Can you promise that no future changes--patches or bugs--will ever break it (assuming it is in fact unhackable)?



Why shouldn't a scripter be allowed to stop others from at least asking permission before part of their work is used to create something else?

What is the collective resource usage penalty for running a "protection" script? (Remember, a protection script will have to be in every copy of "protected" objects in every sim.) People wonder why LSL and sims are so slow, well redundant and badly coded scripts are part of that aren't they? Let the pros (LL) do this.

Can we guarantee that even beginner and novice scripters can successfully protect their work if they have to do it themselves?

Why should I have to do this work that should be built into the system?

Why should I have to further clutter my LSL source with extra protection script crap which could be built into the system?

Also:
From a personal achievement standpoint, why would I want to bother with re-using someone else's non-public domain work, even if I could?
-It's not "right" if you don't have some kind of permission: buying an object is not permission
-You can't call it "yours", you didn't do it all--it is now a "team project" (of course most of the "team" doesn't even know the project exists)

Finally, if nothing else convinces you... many of us don't WANT to waste the time and effort on that crap. Consider it an optional feature request if you insist. But even then it should certainly be put higher priority than alot of the other much more minor "feature requests" we have.

Status quo? No, no, no no no!!

I don't understand the opposition to this concept.

Yeah that's a BAD thing for developers of games. I don't WANT you to own the backpack you buy. If there was another way I would make the game another way. And I have no problems letting people know beforehand that they won't ever OWN anything in darklife.. if it were possible. they can always choose to not play. I think there should be a way to sell services in SL like darklife instead of changing ownership of the backpack to the player.
You think that will result in developers screwing over buyers? I think not, they have no reason too, and they can do that anyway by remote disabling script or calling llDie that deletes the object. But nobody does that. Developers aren't evil...

I do understand your opinion on this. You feel violated in your rights if you can't take the scripts out. But I do think it should be an OPTIONAL permission tag. So before you buy an item you can see what the permission settings are and if you choose to buy it you know what you get... and most items don't need that permission tags.. only game objects and such... just boycot normal items that have that permission settings and creators will know that more people will buy their stuff if they don't enable the script-security...

I haven't read this entire thread.

Lemme just say that the biggest problem here is not quite the fact that scripts can be removed from objects, but that I can't make a scripted object without having that script represented in the contents of the object.

If I make a cube, and it has a texture, and that texture is shown in the contents of the cube, then anyone who owns that cube can remove that texture themselves, whether or not the cube is no-mod.

The problem is that texture-ers can make a cube with a texture WITHOUT letting that texture show up in the contents, thereby protecting their work. Scripters do not have the same protection.

I got into this argument with a Linden about a month back, and suffice it to say he told me quite impolitely to suck it up, shut up, and deal with it. Suffice it to say I've only logged into SL about three or so times since then, and visited the forums as many times. It's very disheartening to not only have a Linden be rude to your face, but also tell you that you're not worth as much as others are by virtue of the fact that your work is not graphical in nature.

Off topic: I noticed before that LindenLab generally care much more about the graphical quality of your creation then the functionality. But they shouldn't, their audience is 18+, and mostly mature people do appriciate the beauty of creations but will not stay long if it doesn't have much functionality (unlike my little brother who almost only judges a game on how good it looks).
You can see how much attention the unreal/chinatown got. No offense to that project, I know it looks beautifull and it might be very cool to pay too (haven't tried). but the fact is LL praised it to heaven JUST because it was beautifull, at a time when the project wasn't finished... it wasn't playable yet by the people and hasn't proven to be a fun game (yet).. bad move form LL...
Ofcourse good looking screenshots is better promotion for SL... maybe that's the point.

but to get back to the topic: LL should give scripters the same rights as texturers....

I agree that this is inconsistant.

Perhaps not suprisingly to anyone who has been reading this thread, I would recommend that textures be treated the same as scripts, in this regard.

"Object" should refer to the physical combination of shaped, linked prims. Their size, relative position, linkorder, material. Nothing else. If I buy a textured object, I should be able to separate texture from object, EVEN if the object is no-mod. I should still be limited by the individual permissions of each component, so that if the texture is no-copy, no-mod, I will still be prevented from mis-using it by downloading it and altering it. If I re-use it in another object, I will only be able to re-use that one instance of it.

Scripters are NOT less important than texturers in SL. Personally, I'm biased and tend to think of them as more important, but I'll go ahead and say that LL should value them equally.

Modes of failure:
1. Scripts remember their states when moved out of an object.
2. Mechanics of listens & Dialog boxs are changed.
3. Memory Corruption
4. Wrong state being entered on script reset.

Likely hood of happening *slim*.
But a random permissions bug making your script mod is more likely.


Fair Use
Why should I have to ask the manufacturer of my car if I can repaint it?


Considering the method I described is passive after activation and all scripts by default get 16k of memory, it should be invisible. Except for memory footprint.


Considering that this is only of interest to game developers and for a totaly comercial endevor of large scale. If security is your interest hire a security expert. A novice has no way of knowing all the ways a system can be hacked or how to protect against them. Hacking a system is more then just pulling the scripts out.


We don't agree it should be built in.


See above answer



If I buy it and it doesn't come packaged with a licensing agreement then I DO have a right to it. And the only time when I DON'T have a right is when you screw up on the permissions when you release it.

If you really don't give a f*** about your customers just add this to your state entry. This way when the script breaks or some other sillyness they have to buy a new one. Planned obselecence.

if(llGetOwner() != "your_key")
    llRemoveInventory(llGetScriptName());

This is what frustrates me, complaints about something that can already be done through scripts with varying levels of options. A check box gives no options.

oh but there is

Have the backpack be a shell. Basicly just an interface for the user to interact with. When they teleport into the sim (or attach) have the backpack request to some land based rezzer to create a follower. This follower contains the guts of the backpack. Because the backpack is just an interface it doesn't need any security at all as it doesn't handle anything important. The other advantage of this is that backpack updates are easy to do. Script security can be totaly ignored now.

Very messy solution, especially for a sim that's lagged, and considering any popular game will be in a lagged sim, the solution is not viable.

I just say that scripts should start getting the same protections texture artists get.

Strife, the idea is funny, but I would never ever use such a unstable and buggy system to create a whole game on. I've minimalized the communications a lot on the backpack and made it as simple and fast as I could but it probably is still sensitive to lag.
It's easy to look at this from a scripter point of view. Probably works when you test it yourself on one person. But when a lot of players play your game, and you are dependable on some central/external database to save your stats, and also on a hidden object that TRIES to follow the players.... well everything could and will go wrong.
Besides.. where does this 'ressez' object gets the player stats from? How do you prevent the hidden object to loose the target on heavy lag, what if you want to expend to two sims? etc. etc.
Ofcourse there are answers/possiblities to these questions, but believe me, you do NOT want to base your whole game on external databases and objects that try to follow the user around you go ahead and try it theory!=reality

But then you are depending on the sim to not crash, attachments don't save properly on a sim crash. The advantage of having the followers keeping the stats is that after a sim crash and the sim comes back up, they still have the stats. If a monster can move around and attach you then a ball can follow you around as well.

Not that I'm saying you should do this just saying it does have advantages.

-----

I think this is part of a bigger issue. What LL wants SL to be.

We were told months ago when permissions came up, slated for 1.7 are revamped permissions (along with new renderer). Permissions aren't a high priority atm.

And it has the severe disadvantage of having to keep a prim in existence at all times for every person who's ever played the game, or forcing the game developer to use the half-implimented XML-RPC code.

How about scripters just get the same protections texture artists get? That sounds fair.

Absolutely, I'd love to be able to rip textures from my objects as well.

Bugs happen, especially in SL or any often updated software, the fact is that it's not possible to guarantee that a scripted solution will work. (Not that a LL solution is unbreakable, but I trust LL not to break their own code more than I trust LL not to break everyone else's scripts.)

---
Fair Use
Why should I have to ask the manufacturer of my car if I can repaint it?
---
I think the fair use concept is different, but anyway that's not the only possible analogy here. If I "buy" a movie DVD I can't use it in my own movie without permission. The same goes for alot of stuff in the "creative/art" realm. If it's free to re-use, it should be offered in a way that lets others re-use it (hardcoded checkbox option), or whatever someone wants to re-use should be made available upon request. This should be up to the creator to decide IMO.

---
Considering the method I described is passive after activation and all scripts by default get 16k of memory, it should be invisible. Except for memory footprint.
---
I'm not sure I agree. I only glanced over the script but I think there was a listener and a timer. That's gotta cost something.

---
Considering that this is only of interest to game developers and for a totaly comercial endevor of large scale. If security is your interest hire a security expert. A novice has no way of knowing all the ways a system can be hacked or how to protect against them. Hacking a system is more then just pulling the scripts out.
---
True enough, although you could argue "why should a novice have to hire someone to do something that should have been hardcoded by LL".

---
If I buy it and it doesn't come packaged with a licensing agreement then I DO have a right to it. And the only time when I DON'T have a right is when you screw up on the permissions when you release it.
---
Legally speaking, nobody actually "owns" anything in SL other than creative content, right? I could be wrong about that. But anyway, I think what we're chipping at here is "what is the informal, implied licensing agreement when you buy something". I think that's where the disagreement lies mainly.

---
If you really don't give a f*** about your customers just add this to your state entry. This way when the script breaks or some other sillyness they have to buy a new one. Planned obselecence.

if(llGetOwner() != "your_key")
    llRemoveInventory(llGetScriptName());

---
That's not very cool, for obvious reasons. Controlling your creative content isn't the same as not giving a f*** about your customers... Nor is not wanting to be inconvenienced by having to write protection scripts and having to constantly make sure they're functioning properly, and not slowing things down. I think that's one of the better arguments for a hardcoded solution.

---
This is what frustrates me, complaints about something that can already be done through scripts with varying levels of options. A check box gives no options.
---
Nah, a check box gives one more option than we currently have--a most likely faster, cleaner, and safer one which saves scripters some time. A check box doesn't prevent you from using a plain script to protect your creations however you want, does it?

Now I'm not saying this should be a *high* priority by any means. Somewhat low really... otherwise I'd be breaking my own philosophy of: "Anything that can already be done in game is lower priority than enabling us to do something that absolutely can't be done yet."

So I think a hardcoded solution would be best, but I'm not organizing any virtual riots in support of it.

You have hit the nail on thee head. I see the permission system as: Permissions you have been granted by the creator. Meaning if the object is mod then the owner has already given permission to modify the object; you don't need to ask permission before rearranging it.

I recall that notecards have some strange permissions when it comes to reading them via script. Being that with the right combination the notecard can not be read by another script if it is taken out of the object it was in but can be read while it is still in that object. The reason for this addition was to keep notecards from being pirated (This was done in responce to me using it to hack the settings notecards used for simcast 5 or 6 months back). This could be used to secure a system but haven't tested the idea for validity yet.

The script I posted does use those but only during the period that it needs activation. If the script is activated or the script is already activated it runs a different state, unloading those. So while the script is activated there is no impact on the sim.

With respect to the controversy around this idea, I've posted it as a proposal on the voting page. That way we can see how much support there is for it. I described it as an optional permission, not a default setting or a change in the current definition of no-modify. I think it would help game developers immensely, and by extension, those SL residents who enjoy playing complex games within SL. We'll see if there are enough people in those two categories to give it any priority. (I know you can't vote against proposals, and this upsets some folks, but given that you can only vote in favor of 10 proposals, I think it will work out.)

neko