Free Idea, someone plz make this

Okay, I'm just too busy now to do this myself, so I'll throw this idea out there for someone to do and take credit for scripting.

Update/email lists.

Create something that a person clicks on and is added to a list - ideal for storeowners announcing new goods.

It could be as simple as keeping a list and having it do a for loop through the list and llInstantMessage() each person with whatever user input that the owner desired.

Please someone do this; it'd be a valuable tool.

Water Rogers wrote a script like this a while ago. I think you can go over to the Reverie and subscribe yourself to their list

Instant messages would probable be a little spammy, if it was me, i'd just give every one on the list a note card. And if they refuse the note card, remove them from the list. And when they click on the object a , a dialog box would pop up. Asking the avatar if they'd like to subscribe the ____ mailing list.

I have a script that kind of like what you want, but not. My version stores vectors, witch are used to set the color of the link set. It was a fun project, but no one seems to be interested in using it. Even if it change their hair color.

If I wasn't already behind in some of my projects, I would do this one. I would make a list of the people which was coordinated with their preference for Notecard or IM.

This brings up a question for me. Let's say you have a "mail box" like this. Can you use a detector od some sort to determine if a player in the list is logged on, then send the choice of an IM or Notecard to that person?

Afterall, "Spammy" you are going to chose to spam yourself, not someone else chosing.

The list would look something like a "Python dictionary":

integer choice;
list userlist; // = [<userkey>, <integer choice>, ...] <---example data

if (preference == "IM")
{
    choice=0; //indicate IM
}
else
{
    choice=1;  /indicate Notecard
}

Something like that...??

I had gathered that such a thing was impractical, because avies could change keys between logins (if not between sims).

Is that not the case?

- yoshi

My understanding was that av's never change keys, but everything else can.

Could always store names too, but I would expect keys to be more space efficient, Though not entirely sure about that considering some of the tricks of using key variables to pass strings.

I had a question, kind of related, but not, is there any way to convert string Names 2 Keys, specifically avatar names to key.

Yoshi, av keys don't change. Keys for attachments change on login, attach/detach or at teleport. Keys for everything else change every time they rez (which is really what is happening in the attachment case).

Kurt, annoyingly not in general. If someone is nearby you can use llSensor to get their key. If not, maybe your script can remember their key from the last time they were nearby. For people I semi-frequently need the key for I keep a notecard with the numbers in

Hiro, your project has some interesting aspects that make it hard to do right and therefore interesting. If I get some time over the weekend I might take a crack at it or part of it (no promises). If anyone else volunteers to be Hiro's code monkey slave before I try this, I'd suggest they need to watch out for:

1. Probably want to click to subscribe and tell the person they have subscribed but tell them to click *again* to get back off the list right away.
   
   
2. If you send people a message, tell them *why* they got the message and that they should go to <sim name> <coordinates> and click the object if they want to unsubscribe. If you've ever run any kind of large e-mail list you'll know how easy it is to get wrongly tagged as a spammer by people who just forgot they subscribed, and it does not do your rep any good at all.
   
   
3. The list might get really large. You need to come up with a solution that isn't going to just lose everything when you run out of script memory. There are lots more avatars than will fit in a script's memory, particularly if you want to remember their names as well.
   
   
4. You probably want to code the data storage separate to the front end, for the same reason. I think this is the interesting bit, actually: making a potentially large data store out of perhaps several scripts each storing part of the whole.
   
   
5. Again to avoid everything going "poof" when something throws a wobbler, having a way to bulk transfer the list into a backup device (another in-world object) would make a whole lot of sense. Also moderately interesting to me as a problem, as I haven't tried to do that before.
   

Just some ideas, really, but I'd guess that the obvious 10- or 20-liner implementation of Hiro's idea probably wouldn't be as useful as it sounded without some of this other stuff in it.

One last thing: before I personally fielded something like this in-world, I'd want to have a Linden tell me it wasn't going to be regarded as a breach of 5.1 (vii) of the TOS. I'm paranoid, of course.

if you're going to have your mailing list give people a notecard each time, include a landmark in the notecard to the place where you click to unsubscribe. just for convenience.

It owuld be easer just to give every one a url to a web site, and let them chose to book mark or not. But why do thing the easy way

Kurt,

The same theory goes for events, and still a lot of people love and use the Event notification.

Alexander,

Good discussion.

For backup, it could be as simple as e-mailing a copy of the list.

Data storage is defintely an interesting question. Consider first that this will be a trivial issue once XMLRPC is 2-way. If you go with a multi-script storage method, you could make a prim for every script to make link messaging easy, but who wants to waste prims? Instead, could just use a bucket storage structure:
- 1 main prim, 1 child prim
- main prim has 3 basic features:
--- accepting owner input - could be from a llListen(1,ownername,ownerkey,"" or it could be reading a notecard. In either event, the message as a whole is read as a string as the content of the email - up to the character limit of an IM.
--- sending - sends message via link - would have two options - request to add/drop a name, and request to retrieve data. it could simply send "change: (first letter of AV name): (AV key)" or "retrieve" as the message
--- receiving - would receive a link message from the child prim with the content being lists of keys. the keys would be the list of avatars to send the mailing to. on link message, the list would be parsed and the string saved from owner input would be sent via llInstantMessage()

- child prim
--- each designated a letter range (bucket)
--- has a list of names in the bucket
--- receiving - receives link message from main prim. would parse, check the first word to see if it's an add/drop request or a data retrieval request.
------ if add/drop request, check if the first letter is in the script's bucket (is "k" between s and u?, etc, however you want to check that). If the correct bucket, cycle through the list of names. if no name found, add. if name found, remove. send an IM to the person and let them know they have been added/removed.
------ if data retrieval request, send the list of names via link message back to the main prim (string format)

...

You could add another function where the main prim, on touch, checks if it is the owner who touches, and if so, sends a "backup" link message. Child prims would then IM / email their list to the owner. - this would be an easy backup function.

*sighs* now look what you've done. I've basically written psuedocode lol!

I made a forum script many moons ago. Khamon Fate has a copy up in his Godeltron thingy. If it's still around, it should be in Zoe.

Sorry i didn't see this earlier

K, i just made this script a few weeks ago as a test... and i've been very suprised by the outcome. Simply make an object, and put the script in... change some simple values, and you got yourself an email gatherer. I've got tons of people on my mailing list in a matter of a few weeks. This can help with getting people who enjoy your products, be informed on new things comming up, the forums here, etc.

The person simply makes a new notecard, names the notecard after their email address, and drops the card in (empty). The script will extract the name, check for simple email syntax, and email you with their name and email address -- which in turn you can add to a mass email program etc to deliver a weekly/bi weekly/whever you feel like it type of e-newsletter.

The object does not hold the notecards to keep the privacy of the subscriber. The script will automatically delete a notecard right after it's received.

Any questions, post.

Enjoy!

string      gObjectName = "Subscribe";  //  object name
string      gDescription = "Touch for Instructions!";  //object description
string      gEmail = "youemail@domain.com";   //  your email address
integer     gHasInstructions = TRUE;  //  FALSE if no instructions
string      gInstructions = "Instructions";  //  notecard name of instructions
integer     gDistance = 5;  //  distance in meters to detect avatar
integer     gAllowGuestDrop = TRUE;   //  allows people to drop notecards
string      gSubject = "Reverie Subscription";  //  your subject line

string      gAgent;
string      gErrorMessage;
string      gNoteName;

func_init(){
    llSetText( "Join our Weekly Newsletter!", <0, 1, 0>, 1 );
    llAllowInventoryDrop( gAllowGuestDrop );
    llSetObjectName( gObjectName );
    llSetObjectDesc( gDescription );
}

integer func_NameParseOk( string agent ){
    integer i = 0;
    for( i = 0 ; i < llGetInventoryNumber( INVENTORY_NOTECARD ) ; i++){
        gNoteName = llGetInventoryName( INVENTORY_NOTECARD, i );
        if( gNoteName != gInstructions ){
            list parsed = llParseString2List( gNoteName, [ "@", "." ], [ ] );
            if ( llGetListLength( parsed ) != 3 ){
                llRemoveInventory(gNoteName);
                gErrorMessage = "Valid Email address must contain a \"@\" and/or a \".\"";
                return FALSE;
            }
            llRemoveInventory(gNoteName);
            return TRUE;
        }
    }
    return FALSE;
}

default{
    state_entry( ){
        func_init( );
    }
    
    on_rez(integer r){
        func_init( );
    }

    touch_start( integer t ){
        if( gHasInstructions ){
            llGiveInventory( llDetectedKey( 0 ), gInstructions );
        }
    }
    
    changed( integer c ){
        if( c == CHANGED_ALLOWED_DROP ){        //  fires when a person other then owner or a person without object permissions drops a card
            if( gHasInstructions ){
                if( llGetInventoryNumber( INVENTORY_NOTECARD ) > 1 ){
                    llSensor( "", "", AGENT, gDistance, TWO_PI );
                }
            }
            else{
                if( llGetInventoryNumber( INVENTORY_NOTECARD ) > 0 ){
                    llSensor( "", "", AGENT, gDistance, TWO_PI );
                }
            }
        }
        else if( c == CHANGED_INVENTORY ){      // fires when the owner or someone with permissions drops a card
            if( gHasInstructions ){
                if( llGetInventoryNumber( INVENTORY_NOTECARD ) > 1 ){
                    llSensor( "", "", AGENT, gDistance, TWO_PI );
                }
            }
            else{
                if( llGetInventoryNumber( INVENTORY_NOTECARD ) > 0 ){
                    llSensor( "", "", AGENT, gDistance, TWO_PI );
                }
            }
        }
    }
    
    sensor( integer s ){
        gAgent = llDetectedName( 0 );
        if( func_NameParseOk( gAgent ) ){
            llSetObjectName( gObjectName + ": " + llDetectedName( 0 ) );
            llSay( 0, "please wait..." );
            llEmail( gEmail , gSubject , gNoteName );
            
            llSay( 0, "Thank you!  You've been added to the list." );
            llSetObjectName( gObjectName );
            
        }
        else{
            llSay( 0, "ERROR: " + gErrorMessage );
        }
    }
    
    no_sensor( ){
        llSay( 0, "Please stand within " + (string)gDistance + " meters of the object when you deliver the notecard" );
    }
}

And my "Instructions" notecard in the object when someone clicks on the object:

Hi!

Would you like to Join our weekly mailing list?  You will recieve information about our products and services and be automatically entered into a drawing for free prizes and gifts -- not to mention be one of the first to hear about up and comming events and products!

To sign up is SIMPLE!

All you have to do is make a new notecard, rename the notecard to your email address, and drag and drop the notecard onto this "Subscribe" object!

It's that EASY!

You will then automatically be entered into our free giveaway drawings and recieve information on our new products!

Best of all, if you would like to unsubscribe at any time, you can do so by clicking a simple link at the bottom of every newletter!

--Best reguards, and thank you for your interest!
--Water Rogers of Reverie.

On the emails, i have a link where you can simply click to unsubscribe.

Nice work Water!

I can't wait to check this out =D I do have a question though... if you are already emailing everyone the weekly, why not just use an SQL database? Just send emails via one-way XML to a PHP script that catalogues the info, then you just type in your latest email in the the box, push send and voila. I assume the biggest issue is processing. However I am on the fence with this, perhaps someone more versed than I can shed some light here.

Would it be less processing to:

A: Keep an in-world notecard container that has a a moderately complex script, which emails the contents from a notecard to the owner of the list

OR

B: Write a simpler in-world script that only sends emails to an outside script on selection (the outside script and database doing all of the processing, should make it easier on the back-end as well)

I would love input on this. I have a "Script upgrades" list that currently does part of what I am suggesting. If the answer is B, or no one has the answer lol, I shall have to write the rest of the coding to test it out. I know SQL databases aren't at everyone's disposal, but if this ends up being the case, I will endeavor to make this available for everyone I can.

Higbee,

Yes, the script i wrote was particularly designed for those of us who don't have access to outside resources other then email. I made it simply to gather email addresses into a filtered folder for hotmail/yahoo... every week i go into the folder and just take those new email addresses and names and add them into a massmailer program. Make up the email to mass email and voila - simple subscription services. Basically i made two filter folders for the email address... one called "subscribe", and another called "unsubscribe" (which is a link they all have at the bottom of each email/newsletter).

There's a bit more of a manual process to this then completely necessary. I 'could' send this to a php script that could gather the needed info and have the php script automatically update a database (such as MySql, etc) on it's own. Or i could go further with this script, and make a 'database' list of names and email addresses. I tend to try and swerve from creating databases out of a bunch of lists and matching indexes in sl, because eventually... if it grows large enough - the script could stack-heap on you. Albeit it might take 100+ entries before happening for a script running only an "add-to-list" type of feature... however there are many things that make lsl too unstable for me to want to do it that way.

If you have access to a webhosting site with MySql and PHP/PERL running on it - you could also take an alternative XML-RPC route by modifying the script to connect that way and send. Lots of ways you can kinda go about doing it... there is no real "best" way. It's all a matter of what exactly you want it to do. My way above isn't fully automated or anything - it checks for simple email syntaxing before sending you the email of their name and address.... but i'm pretty happy with it

Fantastic work Water! Thanks for the insight into your reasons behind it all =D

I am still curious about lag factor, but the new grid is so much more stable I'm giddy as a school girl lol When I get a chance I will run the tests just for the sake of knowledge, if nothing else =D

First, Water's solution to this is cool

I did get round to coding up the in-world alternative to this the other weekend, but only got round to testing it yesterday. This version might be more interesting to people whose customers aren't so happy with handing over their e-mail addresses, or to people who are just more into the immersion thing.

This is a click-to-subscribe, click-to-unsubscribe system. The owner can IM the subscribers, or send each of them an object from inventory. You can dump the list for backup, (painfully) restore a backup by hand, find out how much free memory there is and so on.

The big limitation is that you're limited to probably about 100 subscriptions as that's how many will fit into a single script's memory. The script does check free memory before adding a new subscription, so it should fail safe when the list is full.

I am having a lot of fun thinking about how to extend the capacity by using additional scripts (Hiro's ideas are all sensible, but it wouldn't be fun if I didn't spend a week or two thinking about all the other possibiities that I can use in other contexts), and at some point if there is enough interest a mailing list object with a bigger brain might become available as an upgrade.

If anybody wants one of these, I have left a boxed version on a side table at Europa (105,66) and you can buy one for the grand sum of 1 Linden (non-zero so that I can gauge real interest, mainly). The object is modifiable but the script is closed.

There is a mailing list object for the mailing list object next to the buyable box. It looks like an envelope. Feel free to subscribe, obviously