Jump to content

Scripts double PE...? Really?

Moo Spyker

You are about to reply to a thread that has been inactive for 3778 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Sure do. I just was testing it. You can add dozens of scripts to each part of a linkset, and it still equals just plus 2PE.

At least they didn't make each additional script also counts as +2, that'd suck... this I can deal with.

I don't mind really, cause you can still have a very detailed model equal to just 2PE + add 2PE for scripts.... meh... Its still only 4 prim, beats any non-mesh option easy :matte-motes-bashful-cute-2:

Link to comment
Share on other sites

Drongle McMahon wrote:

Just for you, I did: 200 cube meshes, 200 prims, PE = 200; link them -> 200 prims, PE = 101; add script -> 200 prims, PE = 202.

Edit, misread the middle 101PE

Well that doesnt make any sense at all!

But neither does linking 200 prims into 101 PE, what gives? If its 200 prims unlinked then why would the PE be halved when its linked? surely the server still have 200 prims to render? linked or not?

Why would anyone go to the trouble of making 1 optimised mesh model as a single upload when they can split thier meshes up into hundreds of objects, creating a super inefficent mess, and just link them in world for half the PE?


Link to comment
Share on other sites

This is 100% not true for me, I did multiple tests. first time was on a 8 object linked mesh with a 5 PE. Dropped a sript in PE count went to 10 = DOUBLE. Tried again on a linkset that had 33 PE went to 66.... again DOUBLE. Did a final test on a linkset of 256 objects, and a 128 PE and guess what? PE jumped to 257... DOUBLE where are you getting this + 2 equation thing? If you look on the wiki equation LL posted there is a 2.0 multiplyer for this and physical objects! http://wiki.secondlife.com/wiki/Mesh/Mesh_Server_Weight

Link to comment
Share on other sites

I agree, doubling PE cost for one script, regardless of its complexity or efficiency, is definitely wrong and has to go. If the Lindens wish to find a way to regulate script usage, they should find another way that addresses all scripts, including those worn by avatars. In my opinion scripts in things worn by avatars are the biggest offenders and cause of lag generated by scripts.

LL, we love mesh, but you cannot try to correct all past errors on its back.

Link to comment
Share on other sites

What exactly am I confused about? Look for yourself at the results I got. I guess your cool with being penalized for having efficient mesh's but what I'm seeing here is a DOUBLE increase in PE...


The script I'm adding is a few line script that changes color on a link message... The Mesh itself is very low poly custom physical model and all LOD custom models loaded. VERY EFFICIENT... So why are you cool with this PE effect on script? View all the pictures....

Without scripts 1...


With scripts 1...


Without scripts 2....


With scripts 2...


Link to comment
Share on other sites

If the actual behaviour is different from what i explained in the other thread, then this is either a bug, or the numbers in the wiki are wrong.or i have made a big error in the calculations (which always can be the case). 

Here is what i did with the information i found on the Wiki:

Citation from the wiki:

dynamic_multiplier = 2.0
static_multiplier = 1.0
per_prim_cost = 0.5
base_cost = 1.0

if there are any scripts or the object is physical, active_cost = dynamic_multiplier. Otherwise active_cost = static_multiplier.

Cost scaler is currently 1.0

Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)

Adding the published numbers to the formula:

For non scripted objects:

Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)
Server weight(per prim) = 1.0 * (1.0 * (0.5 + 1.0 / num_prims)
Server weight(per prim) = 0.5 + 1 / num_prims
Server weight = 0.5 * num_prims + 1


For scripted objects:

Server weight(per prim) = cost_scalar * (active_cost * (per_prim_cost + base_cost / num_prims)
Server weight(per prim) = 1.0 * (2.0 * (0.5 + 1.0 / num_prims)
Server weight(per prim) = 1 + 2 / num_prims
Server weight =  1.0 * num_prims + 2

Citation from my post Understanding PE: Server Weight & Scripts:

Since Scripts come into play only in the calculation of the server weigh, adding scripts matters only, if ServerWeight is the dominant weight (which is rarely the case) So it may well be that in your case the dominant weight IS the serverWeight.

Well, after having written this, i want to repeat that i only try to explain what the documentation tells me. If i am wrong then please tell me where i make the false assumption.

Otherwise if the system behaves different from what i explained, then the documentation is wrong or the system is  buggy.


Link to comment
Share on other sites

Well, is the glass half full, or half empty ?...


  • Without scripts the PE for n (well done) prims is effectively halved which is great.
  • With scripts enabled PE equals Primcount+2

So would you prefer to remove the low PE for non scripted objects and put it back to 1 PE per Prim as it was all the time before mesh ?

In that hypothetical case the situation where pretty straight forward:


  • Without scripts PE for a linkset of n (well done) prims is Primcount
  • With scripts PE for the same linkset is Primcount+2

This is much easier to understand... But would you like it more ?

Please don't flame me for writing this. I would also prefer to see less costs and it is not good to see that having done a good job in reducing mesh weights will be just forgotten when you add scripts. Maybe LL has overloocked that we are aiming for most efficiency and the duplication of server weight has been an attempt to protect against bad building habits ?

maybe LL was not aware that the limitting factor nowadays IS the server Weight and not the streaming costs ? Then LL would do best to forget the ServerWeight... btw i asked for forgetting ServerWeight plenty of times in the past weeks. I mentioned in the forum and on the jira and in the Office hours and in private Ims ...

So i am with you when it comes to vote for removing ServerWeight ;-)

Link to comment
Share on other sites

Yeah I would much prefer if adding a script didn't even effect the PE -_-


The ENTIRE PE system is total crap. When you rez an object it should have a FIXED prim count... not one that can change with the slightest thing... Size, Scripts, Physical, Unlinking... all have to go

Link to comment
Share on other sites

Moo Spyker wrote:

Yeah I would much prefer if adding a script didn't even effect the PE


The ENTIRE PE system is total crap. When you rez an object it should have a FIXED prim count... not one that can change with the slightest thing... Size, Scripts, Physical, Unlinking... all have to go

I think, this is over exagerated. When you look at it closer then it might become more sensefull.

Well, as someone mentioned here, most of us (including myself) are no professional game asset developers, but interested selfeducating hobbyists. So we do weird things which would probably never pass any quality assurance in game industry. Hence we need guides to know what is good, what is bad.Telling people how to do things seems to be not enough. Most people will first do, then ask, but never read the docs ;-)

Actually i do not know why a linkset is cheaper than all separated links. I do not why doubling serverWeight is needed when scripts are added. I know very little actually about the reasons why the current accounting system is like it is.

But what i see... is that the current costs system forces us to think into specific directions...

  • Replace a bunch of small objects with a few more complex objects,
  • Reduce lowest LOD to billboards
  • reduce mesh complexity
  • learn optimizing meshes...

So we found ways to drop streaming weight down below 0.5 per prim... apparently you did so. So maybe now Server Weigth does not make any more sense (especially in the situation where all objects are so efficiently built ?

Of course there might be better ways to force us creating better assets. IMHO it is also a bad idea to invent a complex accounting scheme here... Easy understandable, easy controllable, easy explainable would be much more appropriate.

And maybe one day this will happen... Who knows.

Link to comment
Share on other sites

I think I must be missing something here, from this thread I assumed linksets produced less PE, however i just tested this in world by linking a 8PE mesh to a 2PE mesh, after its linked i got 11PE lol.

Yet going by Drongles test, he linked 200 2PE cubes? or were they simply 1PE rounded up to 2? with them linked it provided them with the correct linked value?

If so then whats the point of the test? who is actually going to link heaps of under 2PE meshes? Once you start linking builds with 'normal' PE's like say 10, 12, 8, 10 (40) you would end up with 42+4 per script giving you a PE of 46? if you added another script it would give you a PE of 50? (am i getting this right?)

So in effect scripts only double PE in cases where massive amounts of 1PE or less objects are linked into a linkset?

Im not saying that scripts should add to each object in linkset, they should count once for the whole linkset, im just saying that only in very specific circumstances do scripts actually 'double' PE.

Link to comment
Share on other sites

Its every single case for me. why would you not be adding small PE counted mesh's? With the scale system they have you cannot upload a large mesh to replace multiple small mesh because your charged more PE because you have to make it a larger scale which makes all the LOD costs go up and L$ uploads... Multiple small mesh's is INFINATLY better then a single large mesh. I cannot see myself ever making a single mesh more then 10 PE. Not to mention the stuff I've seen in the mesh sandboxes (no offsense to anyone) but most of it is garbage. This whole system takes into account polygons counts which most people go WAY to overboard. I seen a chair that had like 300 polygons to make up a rounded leg... which could be done with say 20... Theres no reason to have something that small more then 1 PE in the uploader. Point being everything I make will be multiple less then 1 PE items linked together. Noone seems to be thinking about mesh at every angle such as large scale builds...

My builds with mesh among MANY others here who build large scale will make efficent mesh's and keep the PE more then half the cost of the objects in a typical linkset.  So something has got to be done about this. Scripts should not effect PE.


Also Drongles cubes were most likely 6 polygons probably like below 0.1 prims in the uploader so linked remained low PE, your models however most likely had a ton more polygons...

Link to comment
Share on other sites

You will probably be surprised to hear this. It's complicated and I won't rehearse all the arguments here, but the answer is yes. I would prefer that the minimum cost per prim was 1.0 and not 0.5. This would discourage over-fragmented mesh constructions and remove the increased  incentive for using inefficient standard prims instead of new efficient meshes. It would also remove the aggravating effect of the scrpting tax and whatever contortions people would indulge in to circumvent it.You could aim at 1 PE for meshes without having to decide whetherbthey were going to be standalone or linked. As it is, I think the (un)linking effects are going to cause endless confusion and frustration for users new to mesh.

The only problem is that this would be yet another nail in the coffin of the use of simple prim shapes as physics shapes, which would otherwise be the most efficient in many cases. However, this is already so heavily compromised, in part by sever cost, but much worse by the streaming cost of spheres, that alternatives are already needed to make it more useable.

The simplest would be for them to receive the old 0.1 prim cost of they were flagged so that they were never rendered. Much better would be to have the importer recognise the simple sphere box and cylinder in submitted physics meshes and use the appropriate primitives for these instead of hulls.  The former is essentially a new phhysics type and the second woul require lots of cosing and probably anothert streaming format change. So the chance of either being done is something less than zero.

I will admit though that one huge advantage of the script tax did occur to me while writing this. It will make a lot of creators include the provision for colour-changing scripts an such things to be deleted once they have been used. Hmm maybe I will have to change my opinion on that.

Link to comment
Share on other sites

I had posted this elsewhere, but it fits well here and I do not want it to be missed.

I have some sculpted animals that are animated by script for hunting. I had thought about waiting for mesh to make them, but I am glad I did not now. My animals average somewhere around 20 sculpted prims, and each piece has a script in them. If I had tired to do that with mesh, each piece would be a minimum PE of 2, plus at least 1 prim for script, making the animal 60 PE instead of 20. With the penalties applied to mesh, my animals are better done in sculpties.

I plan to make other animals for other types of hunting systems, such as Northern Forest, African Safari, etc. and they will be made as sculpties unless two things happen: 1) it becomes possible to make 1 prim meshes; and 2) the script penalty is removed.

With ten to twelve spawn points and animals roaming a sim at any given time, the prim count becomes very important to sim owners, costing about 200 to 240 prims for the sculpted animals, or 600 to 720 prims for mesh animals. It is not a difficult decision to make.

Link to comment
Share on other sites

If you could make the meshes have average streaming and physics cost of not greater than 0.5 each, so that these do not exceed the server cost, then when you linked them into one animal, they would cost 20*0.5 + 1 = 11 PE. Scripting would make that 20*1 + 2 = 22. Not so different from the sculpty. If we abolish server cost and script tax, then they could have average streaming cost of 1 each, total linkset cost 20, with or without scripts. You are better off with that than with the present scheme as each mesh can be twice the streaming cost.  Whether that (or the 0.5) gives enough detail to compete with the sculpty is a different question. The averaging of the streaming cost means the detail can be better apportioned between the pieces, but still I doubt it will be as good. It might be better textured though!

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3778 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...