Pedlar Decosta

I didn't actually offer a "none of the above" choice Wulfie lol. But fair enough. Can someone explain to me what the perils are that are apparently associated with using notecards ? I am happy to learn about the suggestion of http responses etc, to hard code it. Heck I'd prefer it if there was no copying and pasting at all, and maybe that's the way to go. But before I go down those roads, why is it many coders don't like notecards to begin with ?

So I played around with the code you provided Wulfie, chopped and changed it and used a couple of different tactics to obscure the real uuids (hopefully even from those who read this thread), and integrated it into my scripts, put them alongside each other in the same network and tested to see which one is fastest. Scrambling and the Base64 encryption were a little faster than the XTEA. However, now that I have a scrambled uuid that is the same size as a real key, I can safely put them back into the other lists, dropping the notecard lines down from 6 to 3, which will save a bit of time too. But. and here's the but - you said this is a lazy way of doing it Wulfie, which implies it is not how a fastidious or diligent person would do it and leaves me thinking that if it was your code, you wouldn't do it that way. That concerns me a little bit. I do my best to make my scripts solid, reliable and dependable to do what it is you want them to do with little fuss and low to no lag. So if I add encryption I expect it to be 'fit for purpose'. I have 3 working versions, XTEA, Base64 and something resembling Wulfies scrambing. A question to you Wulfie and others who know more than me about the subject matter, "which would you use if you had to encrypt the uuid's in notecards ?" Bearing in mind that the object is purely to keep the keys safe so as not to breach usage rights and/or to protect the creators own work, and obviously only from an inworld perspective. By the way, in case you are wondering, yes, I think I probably have some level of OCD

Hi Prof. I do use llRemoteScriptPin() for updates and sometimes use so called 'helper scripts'. But considering I use the Reset Function to update network details, the only way to store the lists would be hard coded into the scripts. I could use a notecard for the network channel, thereby not needing to reset the scripts, but I'm not sold on the idea of not having the data hardcoded. ***** happens and people reset scripts and that would render the product useless. That is why I am thinking a mod script the creators can use to hardcode the lists, that they then set as no mod before they sell the product (keeping the UUIDs hidden), is the best way to tackle it from that angle. I know people hate notecards, but in this case they don't have to change a bunch of settings, just paste the chat log readout into a notecard and deposit that into the prim. I've got a version using the XTEA encryption and one using the llBase64() with 'salt' function as suggested by MollyMews. The XTEA is actually not as bad as I thought for time and the Base64 is a couple of seconds faster, but not as secure. I'm faltering on working out a way of scrambling as Wulfie suggested since I cannot yet find any method of actually breaking up strings except by an elaborate use of llParseString2List using all of the ASCII itself as separators. This doesn't seem feasible to me, but then I knew nothing at all about encryption until a week ago lol.

I have been listening to Wulfie's advice about using something like Omega's system. I am guessing the best way to do it is where the creator would use a full perm script to record and 'hardcode' the texture sets into it with them then making it no modify prior to selling the product. And I do think that has some potential. But maybe for an update in the future because I really don't know if the scripts could handle the amount of information (potentially) that could be required. I'm self taught, so with a lot of things I have to have a crack at it, see if it works and come at it from other angles if it doesn't. And read what I can find from the experts. Also as you can see, I am inclined to ask here when I'm in a pickle.Then, because I want to make sure there wont be problems with the scripts, I have an extended testing period where I try over and over to break the script. It's not pretty and it's not very time efficient, but you do the best you can and I enjoy learning as I go.

Hi Phate. I'm assuming you mean what I'd call 'hard coding' the data into the script so that the information is there all the time and would survive resets. But that is not compatible for the way it is used. I still use lists in the way you describe however. Because of the amount of data involved in saving every visual parameter, I use 6 lists. I did use 3 until I decided to use encryption and then I dedicated an entire notecard line & list to each of those encrypted UUIDs.It is not intended to be a HUD, but of course you could easily adapt it to do everything from a HUD instead of from a prim in the object. I also do use a random number routine for the menus, however the channel I use to network other objects can be set by the user manually (putting it in the description and reseting the scripts), by saying the number you want to use in chat (menu dependent), or even allowing the script to create a unique random number by itself and rest itself automatically. I always advise the creator/builder uses a long negative number. Since there does seem to be some confusion and even an idea that these scripts allow end users to change colors and textures etc on products they purchased (which SL already furnishes users with a perfectly capable set of tools to do that with IMHO), however it is not what my scripts do. After a creator/builder/retailer makes a product, they beautify their products using all of those SL tools. My scripts then allow the creator to get a readout of all those visual parameters in their chat log using a Texture Generator. It allows them to even use advanced materials, so a possible 3 textures per face plus all the incidentals. The readout then is copied into a notecard and named something appropriate. Once they do it again using different textures colors and materials and save it also in a notecard, the user (including the end user) can use the menu and choose which of the sets they want. The scripts do other things, but that is the main function of the Texture Plugin. So the creator or whoever adds 2 or 20 or whatever different sets and then gives or sells the product. The end user then has a product with more than one choice for how to make it look. The system is very user friendly. No learning curve at all really for the creator or the end user. I'm running beta tests right now with some furniture which I added about 12 'Texture Sets' to. My original system which I made over a decade ago, had several limitations, like no advanced materials and a limited number of Texturing Sets. And or course I'm adding encryption for the UUIDs in the notecards because I know many creators are concerned about keeping their UUIDs secure. The end user does not have the texture Generator or other builders tools, but can edit the access list, which includes owner only, groups and/or individual avatars, change network channels, update the scripts, rest the scripts, access the help file etc. I should also mention the original system which will also be updated once this is finished adds other plugins like Doors, Windows, Lights, Altitude Setter and user created API's. (I've used it to integrate rising platforms and guard rails as an example). I'm doing the Texture system first because I am aiming it at content creators that wish to value add different looks to their products which include the much superior advanced materials rather than the standard default SL bump & shiny. But of course it also handles those too. My apologies if I am rambling. I just got home and I'm still winding down from a big day.

Hi Qie Niangao. That certainly sounds better. The data isn't always so redundant. That list was a mock up. It was repetitive because I just tried to show how much information there is, not because it is a good representative of an actual usage. Although it is fair to say that sometimes it would be. I do not know how to do what you suggest off the top of my head. I'm also drinking my first coffee, so that could have something to do with it lol Hi VirtualKitten. The problem is the notecards really. They have the UUIDs in them. Which can then be used as far as I can tell. If I sell of give a product away that uses a UUID that has user restrictions i.e. do not allow other people to get these with full perms, or only use them in your projects, then the notecards could be a breach and I don't want to do that. As far as time on my hands goes it is important to remember the bulk of this script has been developed over a more than a decade. 2 things have made me revisit it 1. advanced materials which weren't supported and 2 UUID protection in the notecards. (and since I'm tackling it I'm upgrading a heap of other things too. By the way - I have fun when coding. I love doing it.)

UPDATE: So I fixed the scripts and tidied them up and they are working with the XTEA encryption in the way they should. The only downside is that decrypting and then applying the textures using XTEA has slowed the process down. Instead of typically 5 seconds to finish prior to using encryption, it is now roughly 20 seconds. That isn't so bad, but now I'll take a look at scrambling them to see how much time I can save. I'd be extremely happy if I could get the parameters all set in under 10 seconds. I expect also, that if no advanced materials were being used, there'd be a lot less decryption going on and it would be faster. So I'll be looking at what Wulfie said " The simplest encryption I would recommend for you is simple scrambling. Swap parts of the string around, don't bother with any hashing functions as they're either one-way (useless for you) or so wide-spread that anyone can find a decrypter online. Swapping is simple and others won't know what or how many pieces you changed. "

Something I should actually mention Wulfie is that I actually use resets, so it is a choice on the menu. One thing I use them for is if I change the product description, (I use the description for network channels, so that users can put multiple items into the network), I need to manually reset for this information to be noticed. Think of a bedroom suite that changes it's entire look, just by one menu selection as an example of usage.

Yes, I think you are misunderstanding the model Wulfie. For one thing, there are multiple (sometimes many) notecards for various 'Texture or visual Sets'. All of which will need to be remembered and used (an over simplification would be a color change menu - but with every single visual parameter listed for every face of every prim and for every single menu choice). The end user no longer needs to edit the notecards, but the scripts need them to affect the various changes for each menu choice, again - for every face of every prim. And from what I could tell the Omega scripts didn't encrypt the textures - at least prior to sending them to the no mod script. And because the end user expects to have total confidence that the menu and scripts will never lose the information, resets, as you mentioned, would potentially be a big problem. To give you an idea of how much information I'm talking about for every prim, here's an example. Remembering too that now I am putting the encrypted UUIDs on their own dedicated line in the notecard, 1 for each texture including material textures for each face (in this mock-up 6 faces). Basically it allows the creator to control every visual parameter. I don't know of one that it doesn't include, at least since I added support for the advanced materials (which by themselves is quite a lot of information)/ So picture many of these notecards (I have tested up to 25, but the menu will expand as it needs to, so I'm not sure when exactly you'd encounter problems) ; [01:00] Object: *0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 0.50000, 0.00000>,0,0.000000,0, 0 [01:00] Object: ^0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 0.500000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000 [01:00] Object: ~0,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92079d, <1.000000, 0.500000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !0,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: *1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 1.00000, 0.00000>,0,0.000000,0, 0 [01:00] Object: ^1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 1.570700 [01:00] Object: ~1,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 1.570700, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !1,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: *2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<3.00000, 2.00000, 0.00000>,0,0.000000,0, 0 [01:00] Object: ^2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <3.000000, 2.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000 [01:00] Object: ~2,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <3.000000, 2.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !2,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: *3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,1.570796,<1.00000, 1.00000, 0.00000>,0,0.000000,0, 0 [01:00] Object: ^3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000 [01:00] Object: ~3,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !3,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: *4,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<0.02353, 0.02353, 0.02353>,1.000000,<0.00000, 0.00000, 0.00000>,0.000000,<1.00000, 1.00000, 0.00000>,0,0.000000,2, 0 [01:00] Object: ^4,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000 [01:00] Object: ~4,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !4,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: *5,3fb7b045-3b4e-a966-23a6-b1e3f9c04f92,<1.00000, 1.00000, 1.00000>,0.501961,<0.00000, 0.00000, 0.00000>,0.000000,<1.02322, 1.04781, 0.00000>,0,0.000000,0, 0 [01:00] Object: ^5,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000 [01:00] Object: ~5,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0 [01:00] Object: %5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: &5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 [01:00] Object: !5,2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 **I forgot to remove the original non encrypted UUID's from the lines, so pretend they are not there lol. It is still a fair whack of data though.

I went out & got one, but I can't see what you mean. They essentially just send linked messages to the no mod script. I do this as well, I just don't send texture information, only instructions. Mine also bundles up information and then split it at the other end. Sorry mate, but I'm scratching my head lol. Do they somehow hard code the information in the no mod script ? The only way to do this that I know of is using a remote script pin, which I do use for updates. If you wouldn't mind, I need a bit more information ?

Yeah, I'm not sure Qie Niangao. It is a bit over my head. But if I import a mesh item, rezz it and set it as full perms, take it into my inventory and check it and it is always wrong, so I change it in the inventory and use friends or alt account to double check it arrives with the correct perms. It can be annoying. Hi Wulfie. I use notecards so the information is never lost. Other people use the system to record various sets of textures etc in their own objects. So they can do it once and be confident they won't lose the information. I used to use object description to store data (and still do in other scripts), but with all the various visual parameters (advanced materials etc) there is an awful lot of information. So with all of that info for every face of an object, a notecard seemed the best way to do it. Happy to hear suggestions though ? As far as the encryption I've been working on utilizing the XTEA encryption. It works, except I'm still having a couple of issues integrating it. My issues aren't actually the encryption, but with the code that sets the parameters. I've done something wrong, probably made some silly mistake and I just have to find it. I also put each texture in a list of it's own because of how long it is when encrypted. Here's an example - 2BC4B6936CAA0B7E6FB4BEB781FE58F32D566404E3E8247CBC69C0A3367BBFB20503F634D366BEF9 I did consider trying to do some creative math and/or swapping numbers, but in the end I decided to use (or at least try) something made by the pros. Do you think I should rethink using XTEA and try to make something myself ? I have resisted communicating parameters between prims, like for example using the scripts in the root prim to store and message the other prims their textures or parameters. For a couple of reasons. It is more secure (uuid's for eg), it is quieter (not much chatter) and I've not seen any lag caused by it even though it's quite a large amount of information managed by the scripts. It also keeps it very user friendly and simple to use. There's is virtually no learning curve to be able to use it. You make your product look how you want and then use a parameter generator to form the readout for the notecards. The script makes a menu automatically, based on the notecards and you choose which one you want. Really easy to use.

Although I feel confident now that texture permissions are secure on a non full perm object, I belatedly realized that I was storing the texture UUID's in notecards for all the next owners and possibly others to see. So although Wulfie explained for some people it isn't difficult to grab UUIDs from outside the viewer, I'm doing a crash course in encryption (in my own fashion) to at least keep the UUID's out of people's faces, most of who wouldn't know how to grab textures from 'outside of the viewer'. Because in my mind, any level of security is better than none in my opinion, and it certainly does lower the number of people that would have the ability to abuse the UUIDs.

Hi VirtualKitten. I had realized things had changed simply because after setting permissions on item and then checking them again in my inventory only to find they had changed. I remember a time when whatever permissions you changed on a rezzed item, remained the same once in your inventory. I figured it was extra protection, but man it has caused me some grief, especially causing concern over whether items in an objects inventory had also had their permissions changed as well. I did prefer it when you could set the permissions , take the item and then give or sell it, and have confidence the perms were right. I admit to cursing a lot over this, when for eg a friend says "I can't mod or copy this...". So thanks for your comment. because I felt a bit like Neo in the Matrix and would think "..wait... my reality has just changed.... it didn't used to have that brick wall there...." lol Hi Qie Niangao. thank you so much for that link about the permissions 'slam bit'. I can certainly learn and utilize that information. But I do believe that if I set an object perms to FP and then take it into my inventory, it is inevitably not FP when I check it and have to do the perms again before giving it away or selling it. Which is different from my workflow a decade ago.

You are a legend Wulfie I did the same tests with the object not having full perms and in every case it returns a null key. So essentially, as long as the object is not full permissions, you can rest safe that you aren't breaking the user applied conditions. But if it is a full permission object, they can retrieve the texture UUID. And here I was thinking the texture permissions were what mattered and it was the object itself's permissions. Thank you so much. That makes me rest easier.

Hi, I was under the impression that if you used a texture on an object and that texture was no mod and no copy, and you gave that object to someone else, that they couldn't get the UUID of that texture, even though the object used it. And this seemed to be the case because if you went to the texture TAB it would show a Null Key. But a friend showed me that if she put a script in the object with a simple llGetTexture() function, it would still retrieve the UUID. I own textures that, because of user conditions I'm supposed to protect from other people, but if they can get the UUID, they can just use the texture wherever they like. (Can't they?) On the other hand I have seen scripts on marketplace that claimed to 'encode' or 'hide' the UUIDs. I always thought it was a disingenuous claim as I believed SL already protected them as I just explained. So, my question/s are, what is the actual situation? Do I need to take further steps to hide the UUID's ? If so, how ? I have looked for an answer, but even the UUID lslwiki page doesn't mention protections for textures. Thanks in advance.

Thanks Bec. I kind of explained the face orientation above, but I hadn't thought of changing the blue in settings so that you could leave it on all the time, so that is a great tip, thank you. At some point this model had a mirror modifier applied, however I had uploaded it before with no issues and then I 'expanded' on it. Nothing technical really. Basically just took 2 rectangular parts and made them longer. Even so, I think you may have hit the nail on the head. The face orientation is the result of something, not the cause. A negative scale would seem a sensible culprit. Thank you so much

I'm guessing but I think you are referring to the overlays button, which has a check box in the geometry section for Face Orientation. Blue is right and red is wrong. The shortcut for fixing incorrect faces is SHIFT N with the object or faces selected in Edit Mode.

Hi Animats, thanks for your reply. I didn't even know blender had the option of double sided (or that backface culling meant that even), but no I didn't have that on. In fact I had checked the model for face orientation as part of my normal workflow. The only thing that was out of the ordinary was that originally, when I tried to upload the collada it returned an error for missing level of detail. It only had about 14,000 triangles, no ngons as far as I could see and it was not too dense. I got around this issue (couldn't see anything wrong) by copying the model into a new blender file and exported it from there, instead of where I built it.

I just came up with something I haven't seen before and wondered if anyone knew what the cause was. I was uploading a mesh model from Blender, and when I got it inworld I noticed the face orientation was wrong. I checked the blender model and it was fine, but I reversed the faces none the less and the next import was fine. But the blender model was (of course) wrong lol. Anyone shed some light on why I had this happen ?

ahh. yes. of course. thanks mate. Why didn't I think of that? lol I will break up the lines in the notecard in the first script. And then put them in different lists in the 2nd script to make it easy to apply them in the right place. I think that should fix the problem. Thank you so much.

Hi again Wulfie yes, I thought that might have had something to do with it.But then I was thrown off because the other script generated the entire list without problems every time. Oh well. Everything up to the bump_shiny was under it. So how would you suggest fixing it... would it be better to break it up prior to generating it (in the other script), or here, in the dataserver ? I'm struggling to think of a way to do it in the dataserver event i.e. how to read part of a line for 1 list and then read the 2nd half for another. I guess I could do it with Parsing, but as you say, it does have problems. Which is why I asked for help. Where as it is not difficult to just put the information into 2 lists to begin with. ...I think I answered my own question, but your opinions are appreciated.

Just in case this helps, here is an example of the code that is in the notecard in it's entirety (except there is one for every face) Object: *0,0bbc7abf-3b53-3200-eef9-2be67576db08,<1.00000, 1.00000, 1.00000>,1.000000,<0.00000, 0.00000, 0.00000>,0.000000,<1.00000, 1.00000, 0.00000>,0,0.000000,0, 0,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000,b8e82288-c577-42be-1500-5cadbbe337f2, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, <1.000000, 1.000000, 1.000000>, 51, 0

Hi Rolig and Wulfie, thanks for your replies. Sorry, I thought that code would have the answer in it as that is where the data is being lost. The stuff that comes after it is only able to use the list prior to it falling off. It is basically all about primitive parameters and I have been using it for a few years with no problems UNTIL I decided to update it and add support for advanced materials. So by this code below, it fails at the point half way through the normal material data and subsequently fails the specular as well. The code originally stopped at the bump shiny data. I have added some notes below to show you what I mean. Any help is appreciated dataserver( key queryid, string data ) { list sort; string name; string count; temp = []; if(queryid == QueryID) { if(data != EOF) { if(llGetSubString(data, 0, 0) != "#" && llStringTrim(data, STRING_TRIM) != "" ) { temp = llParseString2List(data, ["*"], []); name = llStringTrim(llToLower(llList2String(temp, 0)), STRING_TRIM); count = llStringTrim(llList2String(temp, 1), STRING_TRIM); sort += llCSV2List(count); llOwnerSay("sort = "+llList2CSV(sort)); //PUT THIS IN TO TRY AND WORK OUT WHAT WAS GOING ON THE RESPONSE WAS - "sort = 0, 0bbc7abf-3b53-3200-eef9-2be67576db08, <1.00000, 1.00000, 1.00000>, 1.000000, <0.00000, 0.00000, 0.00000>, 0.000000, <1.00000, 1.00000, 0.00000>, 0, 0.000000, 0, 0,00000000-0000-0000-0000-000000000000, <1.000000, 1.000000, 0.000000>, <0.0 " WHICH IS WHY I ONLY SUPPLIED THAT PART OF THE CODE Face = llList2Integer(sort,0); Texture = llList2String(sort,1); Color = llList2Vector(sort,2); Alpha = llList2Float(sort,3); Tex_Offset =(vector)llList2String(sort, 4); Tex_Rotation = (float)llList2String(sort, 5); Tex_Scale = (vector)llList2String(sort, 6); llSetTexture( llList2String(sort, 1), Face); llSetColor((vector)llList2String(sort,2),Face); llOffsetTexture(Tex_Offset.x,Tex_Offset.y,Face); llRotateTexture(Tex_Rotation, Face); llScaleTexture(Tex_Scale.x, Tex_Scale.y, Face); llSetLinkPrimitiveParamsFast(LINK_THIS,[Bright,Face,(integer)llList2String(sort,7)]); llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_GLOW,Face,(float)llList2String(sort,8)]); llSetAlpha(Alpha, Face); llSetLinkPrimitiveParamsFast(LINK_THIS,[ PRIM_BUMP_SHINY,Face,(integer)llList2String(sort,9),(integer)llList2String(sort,10)]); // THE OLD CODE ENDED HERE AND NEVER HAD ANY ISSUES llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_NORMAL,Face, llList2String(sort,11),llList2Vector(sort,12), llList2Vector(sort,13), llList2Float(sort,14)]); //HERE IS WHERE THE DATA FAILS, BUT IT IS REALLY HAPPENING BEFORE IT GETS TO THE LIST "SORT" llSetLinkPrimitiveParams(LINK_THIS,[PRIM_SPECULAR,Face,llList2Key(sort,15), llList2Vector(sort,16), llList2Vector(sort,17), llList2Float(sort,18), llList2Vector(sort,19), llList2Integer(sort,20), llList2Integer(sort,21)]); } NotecardLine++; QueryID = llGetNotecardLine( CONFIG_CARD, NotecardLine); } } }

I'm hoping someone will be kind enough to help. I am processing a list into a notecard and then reading that list in another script. It has various data types in the list. In all, there is a total of about 22 elements. Using dataserver I'm processing them back into the correct types and using them. However, (and this has only become a problem once I added more to the list up from 14 separate elements), it is not processing all the data. It seems to fall short around 14 (which is a vector and the list ends like this "<0.0"). I'm concluding this because A: the other data are missing and B: I added a feedback llSay function to evaluate the end processed data. I thought maybe it was a limitation of the data put into a CSV string (like the character limit if you cast a string into open chat), but the other script didn't have a problem making it. I then thought maybe it is a memory problem, so I tried processing twenty two 11 and 12 digit numbers and it processed fine. Perhaps with the various data types it uses more memory and has hit some limit I can't find mentioned ? I'm stumped basically. lol. Can anyone shed some light on it ? dataserver( key queryid, string data ) { list sort; string name; // object name that wrote the CSV string count; temp = []; if(queryid == QueryID) { if(data != EOF) { if(llGetSubString(data, 0, 0) != "#" && llStringTrim(data, STRING_TRIM) != "" ) { temp = llParseString2List(data, ["^"], []); // just to separate the useable data from the name name = llStringTrim(llToLower(llList2String(temp, 0)), STRING_TRIM); count = llStringTrim(llList2String(temp, 1), STRING_TRIM); sort += llCSV2List(count); //Then casting the data back to their types and using them } NotecardLine++; QueryID = llGetNotecardLine( CONFIG_CARD, NotecardLine); } } }

I think you must be right Molly as it only happens when a script is reseting, which often covers the rezzing as well. I'll start adding sleeps either after a listen is initiated or prior to the regionsay. Any guess as to how long would be enough ?