LauraTarnsman

There have been times that I purchased lindens and did not get them credited. However, when I checked back, I also found I had not been charged for them, usually because a credit card associated with my account had expired or had the pin changed and was not updated on the SL system. You should check to see if you were actually charged for the L$, or if the transaction just didn't go through for some reason. Also, if you have alts, check to see if one of the other alts didn't receive the credit. This can happen if you are logged in to SL Dashboard on one account although your viewer is logged in as another. Good luck finding your $L.

What is "cost of ownership" for an object. How is it calculated? The references you provided on land impact are very good ones, and I think my original question has to do with land impact and the two "accounting systems" for the impact of prims. However, I have seen (in my Firestorm viewer, and I can't remember where) an actual estimate in $L with the label "Cost of Ownership". I think I was pointing to an 8-prim object, and the number shown was L$110. I thought it was on the edit screen, near the prim count, but for the life of me I can't find it again, and no, it was not an object set for sale (LOL). I assumed it was a number that somehow showed a periodic cost of owning an object of that land impact, based on some cost of land estimate. It was this calculation that I was looking for. I'll keep looking to find this again so that I can make my question more specific. In the meantime, thanks for the response!

A final report and clarification on this item, and a big thanks to all who helped solve it. Arton was correct in that it was not the presence of a mesh prim in the linkset that broke the PRIM_TYPE call to llSetLinkePrimitiveParams, and Cerise hit the nail on the head, that the call failed to change the sculpt map because it originated from a script in a mesh prim, even though the mesh prim was not the target of the sculpt map change. Moving the script to another prim and making the same call succeeded, so problem solved. The only inconsistency in LSL is that the function call to flip sculpt maps is silently disabled based on the type of prim hosting the script rather than on the type of prim that is the target of the call. Oh well, that's something we can live with, once we know how it works. And thanks again to the great sages on the forum here!

Here is the LL reference to that error message. Perhaps it will help. http://community.secondlife.com/t5/English-Knowledge-Base/Login-failure/ta-p/700109 In my experience, I have seen that message most often when (1) my login sim has gone down (either the sim where you have your home position set or the sim of your last location), or (2) My internet connection has gone dead. However you could also see it if your account had been suspended or you didn't have your viewer pointed to the correct grid (the SL grid). I hope this helps a little.

Thank you THANK YOU! Yes, the script with the call to the llSetLinkPrimitiveParams switching the sculpt map did live in the mesh prim! I can move it to another prim and try what you suggest. Crossing my fingers - won't be inworld to try it until tonight. Dang this forum is good!

Great points! I "register" all the prims in the linkset by matching the linknumber to the prim name at the beginning of the script. So the llSetLinkedPrimitiveParamsFast call with "PRIM_TYPE" is going only to the sculpted prims in the set by linknumber, and not to the mesh prim. When the mesh prim is linked in, the command fails, but when it's out, the command works. Another interesting figment is that when I link 25 prims together, if one of them is this particular mesh prim, it ups my land impact to 27, while the unlinked total is 25. Linking a mesh prim actually causes a 2-prim increase in impact over the unlinked total of the same prims. It is my suspicion that this LL land impact accounting with mesh conveys some new properties to the linkset that disables programmatic sculpt map swapping within the set. The land impact accounting is one thing that seems to connect the linkset issue with the presence of mesh prims within the linkset. If linking to a mesh prim does change the rules for the other prims in scripting, it would be good to gather the details of the changes and add them to the LSL Portal. You put it well, that we must "test the limits ourselves". However it's good to be able to run things by others who may have similar experiences both for new ideas and as a sanity check! Thanks for your thoughtful answers!

Thank you for the reply, Dora! And I do want to carify that I am not trying to change the sculpt map on a mesh prim... just the sculpt map on a sculpted prim, which has already worked in the past, but which quits working when I add a mesh prim to the linkset. Somehow the linkset seems to have changed how it behaves as a result of linking in this one additional prim because it is a mesh prim.

I have an application (a board game) that uses an array of sculpts (pieces). As an option, I allow the user to change from one style of pieces to another. I do this by using llSetLinkPrimitiveParamsFast(PRIM_TYPE...) to swap out the sculpt maps. This worked perfectly until I introduce 1 mesh prim to the linkset. (I know animation using sculpts and meshes is a sore point with LL, and this build does not attempt to do animation). When I link the mesh prim into the linkset, the PRIM_TYPE function quits working. Resetting a sculpt map on a non-mesh prim in the linkeset from the LSL function no longer has any effect, although the sculpt map can be manually edited using the edit tool with "edit linked items". Is this process "borked" by the LL fear of animation abusers? Is there a workaround? Or (hopefully), have I just made some silly mistake? Laura