Creators, could we please be reasonable with this 'no mod' paranoia?

I won't purchase items containing resize scripts as the only way to modify them. I might if it is offered as a choice and I could still copy/mod as normal.

Sometimes, especially with hair, I just want that one small piece to either the left, right, forwards or backwards. I don't want to edit the whole thing and I certainly don't want to resize it. I just want adjust positions, so it looks better on my avatar.

I also won't sell anything with a resize script. With so many designers using them as a way around the whole paranoia over the mod/copy thing, if I did use them that's what people would assume I was trying to do also... even if I offered mod/copy along with the scripts.

If the item has scripts in addition yes fine though i'd wonder about the ability of some to go through the process of reinjecting scripts.

The opinion part I was referring to was that the items are too complex for people.

It's actually not opinion if you want to argue it, it's factually wrong. There ARE people for whom those items would not be too complex. So my mistake, it was actually a statement not an opinion therefore, it's wrong

That's just a matter of inadequate scripting. I'm sure it's possible to independently adjust any one of the three dimensions or coordinates of a prim via code and a decent resize script should allow the user to do so. These scripts can be a very useful feature for those residents who are not sufficiently knowledgeable, confident or dexterous to use the editing tools in SL.

At the end of the day, they are no different to any other script in that they will be a nuisance if not properly used or, worse still, if they are badly written in the first place. The better examples can be deleted at the click of a button, which should be a standard feature, and it's even feasible for them to self-delete if, for whatever reason, owners do not delete them.

The poor reaction to resize scripts is largely due to the ignorance and selfishness of creators pointlessly seeking to protect their trade secrets by restricting permissions. The general inefficiency of resize scripts is also indirectly due to this paranoia about copying: a script in every prim would not be at all necessary if the Lindens were to allow a simple function like llSetLinkPrimitiveParams. Unfortunately, a vocal body of opinion holds that the introduction of such a function would open the gates of copy-bot Hell.

As it stands, there is still no good reason why a scripted resize feature should not be included in objects along with modify permissions at least - and preferably copy permissions as well - so that customers have a choice in how they wish to go about fitting items according to their needs and abilities.

And there are people for whom the items would undoubtedly be too complex. Lamb sakes what was your point other than to simply gainsay me?

You've identified the problem. "a prim".

Modifying a belt where there might be a belt loop sculpt, inner and outer parts, a couple of pieces for the eyelet. doing each one of those, for however many eyelets and loops exist by clicking each prim, choosing each direction, how much is absolutely infeasible. TOTALLY.

Normally, we'd just edit linked parts, chose the ones we want and move.

/me shakes head.

Anyone who believes that these cripple tools can reshape is deluded. Send me an IM, i'll send you a shape and where to buy an example belt from. I'll pay for the belt if you succeed in a sensible manner quicker than doing it by editing linked parts or even without much frustration.

Apart from the fact that you clearly like to justify your preconceptions by picking and choosing arguments out of whatever you read, I have identified no problem here.

You haven't looked into the available range of "these crippled tools", have you? Because there are scripts that not only allow the user to modify an object prim-by-prim but the texturing and position of the individual prims to boot.

I would not disagree that it is bad when creators restrict permissions on their objects, thereby forcing customers to rely exclusively on resize scripting. Also I would not disagree that these scripts are a persistent drain on sim resources if they are not removed. Nevertheless, neither issue makes scripted resizing a bad thing in itself.

And I'll say it again: not everyone is capable or even aware of how to use the editing tools but that is no reason why they should be deprived of the ability to modify their objects. The issue is really about using common sense and having some consideration for others.

1. There's simply no way to script an object with more than two prims such that making any possible adjustment to an individual prim is easier by script than it is in the editor. It's really not a question of script complexity, it's a matter of having a reasonable UI to perform spatial operations. The editor is such an interface; dialog boxes and llDetectedTouch*() are not.

2. It's sorta sad that we're forcing newbies to learn these resizing script UIs--each clunky in a different way from every other, so whatever they learn is guaranteed to be immediately useless for any other purpose. If they had no choice but to learn the Editor, they'd be able to use that for everything. (... for everything that hasn't been crippled by no-mod permissions, that is.) No wonder the poor darlin's never learnt to use the Editor--they've had to spend so much time in-world learning to operate different resizing scripts.

3. If one absolutely, positively had to have resize scripts, it seems to me that they're inordinately complicated. Whatever geometry that's going on in those child prims, it's deterministic enough that the script shouldn't need to do llGetPrimitiveParams() inside those prims every time it wants to adjust them: those prims are gonna be pretty much wherever the script last put them. So why not just do the adjustment from llSetLinkPrimitiveParams() scripts in the root prim, based on memory of each prim's local pos & rot? If 200msec per prim is too slow, maybe a few slave scripts in the root prim. On reset, the script just reverts everything to the original "default" configuration (which it also keeps in memory). Why wouldn't this work, and save both scripting effort and runtime resources?

(Not that I wouldn't like llGetLinkPrimitiveParams() nonetheless.)

4. Texturing is different because I don't think anyone does texturing using individual child prim-resident scripts, ever since llSetLinkPrimitiveParams(), unless they're already stuck with scripts in those child prims for pos & rot adjustments.

"no mod" is not "moddable". Period. Even if they do disclose it's via a script I consider referring to "no mod with a script" as "mod" fundamentally dishonest.

Because the original "default" configuration held in memory is wiped on reset?

Oh, I wasn't clear. I meant that the default config uses memory size--but is populated from a list of constants in the script or to make it easier for content creators, maybe, from a notecard. It would be part of setting up the resizable product to first run a report on the default pos & rot of the individual child prims and store that either in a notecard or the script itself.

You didn't address the part where I gave an example of a 200 prim belt or whatever I said, with multiple parts per loop and eyelets.

I KNOW there are scripts where you can click per prim and move and rotate and they are utterly useless for anything over a handful of prims. One simple problem is you have to be able to click on the right prim and with overlapping objects with transparency that's nigh on impossible at times.

I'm merely speaking from pained experience as a user here, they don't work. As a creator, I won't insult people by giving them crippled products. If they're a newbie, learning how to do it properly is a good experience that will stand them well.

For the rest, see what Qie said. He understands it quite well!

(and i'm not picking and choosing to suit myself, i'm just not going to endlessly debate something which is patently obvious nor pick apart each sentence. I'm done here, cripple scripts are just that, nothing more. No need to shop there).

I went the extra step and purchased the Creator version of a resize script system I like very much. For 90% of the items I have to resize, it is fantastic. It gets it close, and then with just minor touches I am done.

For the other 10%, they are usually skirts or belts where the person who made it is a oval person. Then it takes tons of work to get it to fit right, esp when they used 100 prims for added touches.

When I am done editing, the script has a handy Delete button, and it's all gone.

I do not like the items where they made the item no mod, and then add the script. Because often I have to make the skirt panels shorter also, and you just can't do that with the resize scripts. Also, those people tend to use the scripts that don't have the delete button, so teleports and sim crossings become much harder.

I notice that whenever a discussion comes up about mod/no mod, everyone always takes the conversation to clothes.

How about opinions on things such as vehicles, weapons?

Vehicles definitely should be mod (and copy). People like to personalize their vehicles with a different appearance, and it's much more fun for RP. Copy is essential because losing a non copy vehicle due to a sim crossing or other SL issue is very unfortunate. I refuse to buy no mod or no copy vehicles, and most of my friends feel the same way.

I cannot speak to weapons as I do not use many but I would suspect I'd want them to be modify so that I can add my personal touches. One of my friends in world buys only mod weapons and usually tints them pink -- her signature colour.

It's the ability to mod vehicles, weapons, clothes and more that make SL a much more enjoyable and personal experience.

You mean there are resize scripts that don't? I frequently use X/Y/Z independent resizing via resize scripts.

It's unfortunate that there's no good way to judge the quality of resize scripts before buying an item. But there are good ones out there that address many of the concerns raised here.

I disagree. I can resize something by 1% easily using a resize menu. I can't do it with the editor handles. Not that I don't know how, but that I can't make that fine of an adjustment using my touchpad or mouse. And it's certainly easier using a single button than to find the right boxes and type the numbers.

Far more important is that resize scripts provide an approximation to multistep undo/redo, something that the editor is totally lacking.

It isn't right to generalise like that. I can think of quite a few items I made myself where most of the donkey work of modification could be saved via a script and the editing tool would come into its own where tweaking is required. A big flaw in the editing dialog is that grouped objects can only be stretched uniformly. It isn't possible to stretch or reduce the selection along a particular axis, whereas a good resize script can do this.


Fact is I know quite a few residents of a couple of years or more who neither know how nor even want to edit prims. It's a drag for many folk where a little button clicking on a menu would suit them very well. I think the problem is that there isn't a good open source script that creators can provide with their products or I have yet to see one at least. So we get all these variations, some better than others, and of course the foolish attitude of some creators who believe that a scripted resize system somehow gives them the right to restrict modify permissions under false pretences.


Would that really matter if, at the end of the day, the 'life' of a scripting system were limited to, say, one session or a time period of modification?


Apologies, I mentioned llSetLinkPrimitiveParams() earlier, which is an existing function. I was thinking of the complementary llGetLinkPrimitiveParams.

Yeah, I grant that *one* operation (simultaneously resizing all the prims) might be easier with a resize script, but the topic was about resizing individual prims and rotating them and doing all sorts of stuff, which is why I referred to llDetectedTouch*() and said "any possible adjustment." (Perhaps that would have been more clearly put as "arbitrary adjustments."

I'd sure like undo / redo in the editor; I wouldn't give a plug nickel for it in a product resizer script (although possibly, if the resizer script is used as a building aid; that distinction arises again below).
But as I said above, it was the general case to which I was responding: the all-singing all-dancing resizing/retexturing/re-everything script that I think it was you who introduced to the thread.
Yeah, I think I can imagine applications for that (although not for any product I've ever found to have a resize script; would be useful sometimes as a building aid, though).
It may, if avatar script memory limits mean that one can either resize one's hair or wear an AO, but not both at the same time. But mostly I was just riffing on Damani's theme, exploring the least resource-demanding script approach and avoiding llRemoteLoadScriptPin() because it's a bit of sim overhead compared to not having a script resident in the prim at all.

You know, actually... I don't think I have a problem with a general-purpose resize script that an individual consumer may learn to use and insert in products they buy that they find difficult to use the editor to resize. At least they wouldn't have to learn another idiosyncratic resize script each time, and they could use the same scripts for anything they might build. So I agree that there might be a place for a selection of free open source resize scripts, as long as creators didn't include one in their products, and especially didn't use it as an excuse to make those products no-mod.

!?

The editor has Undo/Redo. It even works for individual prims in a linked object. I admit it can be hard to follow when the connection is iffy with packet loss delays or whatever and like most things in SL it doesn't work at all on occasion but all the same it's there - I've used it quite a number of times today.


That's another good idea I might consider myself. Creators could offer a 'Resize' package in their store or better still include it as separate content in the delivery box. It's probably the better option since the customer would have to rez a copy of the product in-world in order to inject the scripts, thereby ensuring they have a fall-back since they won't mess up the original item through an oversight. It would also provide a good opportunity to acquaint them with a notecard of tips and a warning about the implications of not removing the scripts when they're done.

Of course it wouldn't help shysters who want to side step the fact they locked up mod permissions despite their advertising.

To cut a long story short, I'm not an all-out advocate of resizing over editing but I find that discussion of the issue often gets too slanted by criticism of paranoid creators restricting permissions. I would still hold that a well thought-out resize script can be a useful tool in tandem with mod/copy permissions. In the end, it's just a matter of how scripted resizing is presented to the customer.

I wonder if Torley has done a vidtut on this. If not...this might be a great one to do!

Re: hair, I can highly recommend one place *to* shop that doesn't use resize scripts - Analog Dog. And now some of her older styles (that are still wonderful imo) are in the bargain section for like $50L or less iirc.

if resize scripts are adding that much time.... the people buying them seriously need to look into finding better ones. It 'should' only take ONE script to handle doing resize on every prim in the object... not 1 script per prim. And if it's scripted right, it won't be adding lag.

(I'd completely lost track of this thread until it popped up again today.)Yes, I use it too. It seems to remember what's been done within a session, which is generally fine for my purposes, *except* it only works for prim dimensions / rotation / position, at least in my experience, not textures, and especially not texture repeats and alignment. That isn't relevant to resizing scripts per se, but I took Kidd's comment to be about the larger capabilities we'd been discussing including texture changing.

It could be that the Editor knows how to undo/redo texture stuff too, and I'm just doing something wrong. What tends to bite me most often is undoing a resize with the Scale Textures radio button toggled from its setting when I did the original resize. (For that matter, turning off Scale Textures can have some pretty funky results anyway, on hollow faces for example. I haven't studied it closely enough, however, to be able to file a coherent jira about it.)

stfu*

Check out the freebie blogs regularly. There are free or cheap winter scarfs listed ALL the time.

Scarfs are all over SL right now...maybe find a freebie and ditch the other one. But, yeah.