Darkie Minotaur

You're doing it right: body would contain the data. Coold it be that you're doing something wrong in sending the data? The LSL code seems ok to me.

Your header information needs a little tweaking - this works perfectly for me: string url = "stream-url";key HTTPRequestKey;default{ state_entry() { } touch_start(integer total_number) { HTTPRequestKey=llHTTPRequest(url + "/stats?sid=1 HTTP/1.0\nUser-Agent: XML Getter (Mozilla Compatible)\n\n",[],""); } http_response(key k,integer status, list meta, string body) { if(k != HTTPRequestKey) { llSay(0," nope"); return; } else { llOwnerSay(" got \n" + body); } }} If you need a v2 server for testing, just contact me inworld. I have a server which I don't however run all the time.

What would such an example be? I can assure you, I didn't type the response I posted by hand

As I stated earler: in version 2, 7.html is gone. But there is a public interface - stats. If you call (sid is the stream id) http://myserver:myport/stats?sid=1 You will get a reply that looks something like: <SHOUTCASTSERVER><CURRENTLISTENERS>1</CURRENTLISTENERS><PEAKLISTENERS>1</PEAKLISTENERS><MAXLISTENERS>32</MAXLISTENERS><UNIQUELISTENERS>1</UNIQUELISTENERS><AVERAGETIME>361</AVERAGETIME><SERVERGENRE>Misc</SERVERGENRE><SERVERURL>http://www.shoutcast.com</SERVERURL><SERVERTITLE>myServer</SERVERTITLE><SONGTITLE>2raumwohnung - Sexy girl (English Version) (Bonus Track)</SONGTITLE><NEXTTITLE>2raumwohnung - Sasha (Sex Secret)</NEXTTITLE><STREAMHITS>1</STREAMHITS><STREAMSTATUS>1</STREAMSTATUS><STREAMPATH>/test.aac</STREAMPATH><BITRATE>48</BITRATE><CONTENT>audio/aacp</CONTENT><VERSION>2.0.0.29 (posix(linux x64))</VERSION></SHOUTCASTSERVER>

I haven't used or tried it myself, but v2 has /stats that provides information an XML format

I don't know an off the shelf solution for that - but it's deffnetly feasible. As for the rental aspect, some of th rental systems offer handling stream rentsls - but they usualy extend beyond the scope of handling payments, payment extensions etc. The actual stream and server management bits are a manual process. If you want a custom system, you can contact me inworld.

You shuld be a bit more specific. Selling streams could mean anything from giving out notecards (each notecard just once) to a full automated system that sets up the servers, handles subscriptions etc.

Note that this will only work if there's an ava run in a viewer which has set the channel to the specific channel is close by (I don't actually know which communication command Firestorm uses.). If you want a script that displays the song currently played in a certain stream in a parcel independently of a certain ava present, you would have to use the notorious page 7.html and poll it with a timer.

It would be helpful to know where you're starting from. do you know scripting/programming at all? if yes, have yu done anything with LSL)

Do you get any errors or hints, that will help to track down where the script fails? If not, try to place some llOwnerSay functions so you can see where the scripts get to and where not.

You're welcome. If you can't solve the riddle - just come back

I didn't go through the scripts in detail - but here are the obvious points: llEmail - the order of the arguments seems to wrong - look in the wiki apart from the fact that the address should come fist, then the subject should follow and finally the message body, the variabe body in llEmail never gets declared neither does it get set. in the third script, the variable total_sold never gets declared

You never set gAccess - so the test in touch_start in the state running never get evaluated to TRUE.

You would either put scripts inside the prims that should change their textures and inform them through a 'master script' to change the texture. Or you use llSetLinkPrimitiveParamsFast. Since linknumbers can change, I would loop through the prims and change the prims with a certeain name.

You can't use llDie on an atachment Your status == 200 should be just the other way round - if the status is 200, everything is fine save the 'used' flag in the database - this way you can make sure a gift card is used just once look here

Use llVecMag()

I guess that's one business idea: Get someone to pay extraordinary prices for land

It's a bit difficult to give you advice without knowing how you exactly want the gift card thinggie to work. But you seem to use an external databse. So, as for question one: Keep track of to whom you've given a gift card and who has used it. Since you most likely make the cards no copy, the uuid should be a good identifier. Simply check the database on attaching the gift card. Question 2: Simply define how you want it to work. Question 3: You can't. At least not in a script that is in the area in question - because you'd need a script, which wouldn't run in a no-script area. Question 4: Make a request and see if you get a response with status 200

The listener itself doesn't give you the option to just listen to the owner's object. The best you can do is to listen to a low negative channel and then inside the listen event check if the sender has the same owner: listen( integer channel, string name, key id, string inputstring ) { if(llGetOwner() == llGetOwnerKey(id)) { .... } }

On the list you named, there are the convertion rules - what else do you need - it's pretty straight forward. If you're looking for a script, this is the wrong place.

Have a look at the SimpleDialogMenuSystem in the Scripting Library.

The problem is, that the second messages never reaches the target. Each llSay in the first script wil trigger listen event in the second one alright. But since you always check if ( (key)inputstring == owner ) before continuing, the second llSay will never be processed. If you want to work with two separate events, There is a number of ways to do what you want - what ays would be best depends on the actual task you want to do. Just as a simple demonstration,I would propose something like: integer giChan = -53674567;default{ state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(giChan, (string)llDetectedKey(0)); //we want to wait for a monent llSleep(1.0); //we change the channel now to the secret channel integer secChan = ((integer)("0x"+llGetSubString(llDetectedKey(0), 8, 0))) * -1; llSay(0, (string)secChan); llSay(secChan, "1225"); }} And: integer giChan = -53674567;integer giVerificationPending = 0;float gfTimeout = 7.0;integer giSecretChan;integer giListener;default{ state_entry() { llSay(0, "Hello, Avatar!"); giListener = llListen( giChan, "", NULL_KEY, "" ); //you shold take a very low negative channel number here } listen( integer channel, string name, key id, string inputstring ) { llListenRemove(giListener); //we delete the old listener llSetTimerEvent(0); //stop the timer key owner = llGetOwnerKey(id); if ( (key)inputstring == owner ) { //set a flag that lets the script know that we are listening for a 2nd message giVerificationPending = 1; llSay(0, "I know you clicked the passcode and not someone else! Now checking passcode."); //now we generate a new channel number based on the key giSecretChan = ((integer)("0x"+llGetSubString(inputstring, 8, 0))) * -1; llSay(0, (string)giSecretChan); //and now we listen to this new channel - and we listen to the sender of the first message only giListener = llListen(giSecretChan, "", id, "" ); //we want to close the listener, if no 2nd message is sent llSetTimerEvent(gfTimeout); //only accept, if the inputstring is correct AND if we are waiting for a verification at all } else if (giVerificationPending && inputstring == "1225" ) { llSay(0, "passcode verified."); giVerificationPending = 0; } else { llSay(0, "passcode error."); giVerificationPending = 0; } } //if no 2nd message arrives on time timer() { llSetTimerEvent(0); giVerificationPending = 0; llListenRemove(giListener); llSay(0, "I never received a pass code!"); }} This more of an example for what posibilities there are than a solution you should use.

*chuckles* Thank you for the hint. That must have forgotten to take that out after debugging.

Das ist Quatsch - natuerlich kann man mit einem verifizierten Konto oder einer verifizierten KK jederzeit per PayPal zahlen - wer des Lesens mächtig ist, kann das auch nachlesen. Also bitte nicht auf angebliche Fehlinformationen rausreden.

Since name2key services have cause problems at several occations in the recent past, I decided to add another one. These services are usually provided by residents on the basis of their private webspace and the maintanance is a matter of their available spare time (just as with me), I thought it would be a good idea to offer another one. You will find it here: Darkie's name2key service It's in the beta stage - let me know if there are problems you encounter. Feel free to use it - and contribute