![](http://content.invisioncic.com/Mseclife/set_resources_8/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
Monica Balut
-
Posts
76 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Monica Balut
-
-
Thank you everyone for your suggestions.
I stuggled with this most of last night and ended up with a method that is most similar to what Darius, Ron and Darkie describe.
I have a list of notecards which I've created elsewhere that are ones that have the same name as what another object (the installer) proposes to send. The aim is to allow the user to first delete the existing one or to keep it and have the new one iinstalled with a numerical suffix.
I decided to avoid doing anything that involves state changes since I would lose listens that I count on being there later.
At the end of the function that creates my list of duplcate notecards, I call PocessDupNCList() which looks something like this:
ProcessDupNCList()
{
if (dupNCList != [])
{
AlertABoutDialog(); // tells the user in chat to attend to the dialog
currentDupNC = llList2String(dupNCList,0);
dupNCList = llDeleteSubList(dupNCList,0,0);
llDialog(owner,"The installer wants to install a notecard named " + currentDupNC + " but one by that name is already in the object. What should we do with the notecard in the object? (Clicking on Ignore will abort the installation.)",["Delete it","Keep it"],INSTALLCHANNEL);
}
else
{
currentDupNC = "";
FinalReview();
}
}then in my listen event I have code that looks like this:
...
if (message == "Delete it")
{
delNCList = delNCList + currentDupNC;
ProcessDupNCList();
}
else if (message == "Keep it")
{
keepNCList = keepNCList + currentDupNC;
ProcessDupNCList();
}So, it only goes on to the next item in the list if one of those two buttons is pressed.
To deal with the Ignore, I set up a timer. When it times out, I just reset everything.
Hitting ignore effectively aborts the process and prevents the code from going to the final review and installation. If the user were to restart this process, all the variables would be reset to their orighinal values.
-
I generate a list of note cards in an object that I want to allow the user to delete or keep by asking for a response via llDialog. My code goes like this:
while (NCList != [])
{
currentNC = llList2String(NCList,0);
NCList = llDeleteSubList(NCList,0,0);
llDialog(owner,"What do you want to do with this note card? " + currentNC, ["Delete it","Keep it"],CHANNEL);
}I would have thought that a bunch of dialogs would have been stack on top of each other which would allow the user to process the stack and address each one.
However, instead only one current dialog appears and I can see the text updating for each note card as the code goes through the while loop but only the last one stays on screen for the user to process.
What I want is to go thru a list and force the user to address each note card on the list. I thought of going to a separate state and only returining when one of the two options is clicked. That damned "Ignore" button is the weak link in this. I just know that someone will hit it and thereby hang the whole operation despite any warning against hitting it. I thought of putting in a timer in the processing state but that has its own set of problems.
I'd appreciate any suggestions on how to go through a list like this while forcing a response from the user to each item in the list.
-
Is there a way to detect which viewer the user is using. I don't see a way to do this in LSL. Am I missing something? What i's like to know is which of the TPV's is being used as well as the version.
-
I took your suggestion Rolig and came up with something that works pretty well. This installer is only loading animations and notecards. I have the installer send the name and creator of the animations to the HUD which checks if they already are in its inventory and deletes them if they are. With notecards I just send the name and don't delete the one in the HUD if found. I just warn the user that the new notecard will have an integer appended to it. Then I just llGiveInventory all the animations and notecards.
Thanks for unmuddling my brain.
-
I'm creating an installer package that is rezzed and that will llGiveInventory to another object being worn as a HUD. I can easily make the installer.
One glitch however is the possibility that the object may already contain the same item (animation or notecard). llGiveInventory will give a duplicate item to to the object and there doesn't seem to be a way to prevent that.
So, I thought of putting a function in the receiving object to allow the user to remove duplicate items. Items given by llGiveInventory in this way all return the NULL key to llGetInventoryKey so I can't just compare keys. Duplicate items usually have an integer appended to the name. However, there could also be legitimately different items that happen to be named the same except for a sp-integer suffix.
I want to keep the newest added copy and delete all the other duplicates.
I'm having difficulty wrapping my head around an efficient and even reliable algorithm that will accomplish this. There could be 1000 or so items to check in the object's inventory. Everything I can think of would likely be slow as molasses or could delete legitimate items.
Could someone point me to an efficient algorithm to keep the newest duplicates and delete the older ones?
Perhaps I'm going about this all wrong and there's a simpler way to ensure that an installer doesn't give items that are already in the receiver's inventory. Any insights would be appreciated.
Detecting viewer used?
in LSL Scripting
Posted
Wow I had no idea of the potential problems with this. My intent was quite simple. I have a script in a HUD that positions the HUD on the screen. What I've found is the Kirsten viewer positions things diffently. For example, I can set the z postion of the HUD to Z. When I open using Kirsten that same Z position is higher on the screen than the standard SL viewer thereby requiring the user to manually move it down. My thought is if I knew the viewer, I could accomodate to this.
I guess the answer is that it can't easily be done and not likely avaiable because of potential for bad things. I'll just have to choose a Z value that accommodates most viewers.