Domitan Redenblack

"August was the biggest growth month for Second Life in nearly four years, with Q3 averaging 45 percent more completed registrations per day than Q1 before the new reg flow was implemented..." Yet in the same report, user hours have dropped by 4% ... Clearly LL are doing something wrong if more people are joining, but user hours are going down. What do you think?

PeterCanessa Oh wrote: Domitan Redenblack wrote: There is a product in MarketPlace which sends SMS text messages to phone number Yes, but the point is it almost certainly uses a off-world server to convert the HTTP request (presumably) to an SMS Yes, I should have stated that.

Just Dinkin wrote: If I'm not mistaken, there is a way to integrate/link a jabber server with msn, yahoo, and aim. Assuming you run your own jabber server and have it linked to those other IM services, using a script like sendxmpp would allow you to send an IM across any of those networks. There may be an easier way to do this though. I will look into it more and see if I find any easier ways to do this. Thanks. Seems like it might make a good resource for SL. There is a product in MarketPlace which sends SMS text messages to phone numbers (around the world) which cost about 16 cents each. That's fine for small numbers of messages to people who are not on GoogleTalk etc. (CheapSMS https://marketplace.secondlife.com/p/cheapSMS-English/2603376)

I am not seeing this problem any more. Must have been a glitch in the servers or something. 1. edit notecard inside an object 2. change event happens, and I watch lines being read from the changed notecard 3. the lines I see do not include the new lines I added to the notecard 4. if I wait and use LSL to read the notecard again, later, the new lines do appear Not sure, I will just chalk this up to a glitch thanks all

Hmmm... I was using a standard notecard reader script, which re-reads upon change (as in the Wiki sample: Notecard) I found that when I made changes to the notecard in world, these changes were not always seen upon Change-Even re-read ! Have others noted this? Will this help? changed(integer change) { // Read Notecard when it's been changed if (change & CHANGED_INVENTORY) { llSleep(5); // give inventory servers a chance to catch up myConfig_init(); // re-reads notecard } }

For Google Talk: Any client that supports Jabber/XMPP can connect to the Google Talk service. As long as you adhere to the requirements of the XMPP specs, you will be able to connect to the Google Talk service. You need to know the following: The service is hosted at talk.google.com on port 5222 TLS is required The only supported authentication mechanism is SASL PLAIN What do you think? Possible?

How about sending an SMS from a script in SL?

Anyone know of a way to send a message to Yahoo/GoogleTalk instant Messengers from within SL?

In addition to seeing more problems in general, certainly related to LL servers (which have been slow mostly for a week), I have some "persistent texture offenders"... These are items that do not rezz but must already be in my cache. When I zoom in on them, they sometimes rezz, but always cause trouble. There is one tree that is always fully GRAY, even when everything else in the sim is rezzed. If I zoom in on it, it eventually rezzes every time. Right-click editting it does not help, I have to zoom in. Very strange. I have cleared the cache and restarted several times, and this one tree and some other textures are persistent offenders. I emphasize that this is New Behaviour. I cannot understand why a texture which should be in the cache, and is not tinier than the surrounding textures (trees) should fail to load, even after a long time (20 mintues or more) until I zoom in on it. Note: I have also noted my log in screen (Phoenix) has been very slow (5-10x slower), off and on, which I assume means it cannot load the remote info about world visits, grid status, LL news etc. Several times today this was fast. I checked other USA sites, and they loaded very fast, just as usual.

There are hundreds of bugs in SL now, that are totally ignored by LL et al, in favour of new stuff with bugs. Texture loading suddenly seems much much less reliable in the last week or so... Why? Is this human nature, or bad bad bad management at Woob Woob Labs? imho: LL are the Three Stooges of coporate management... Woob woob woob woob °͜°

There are hundreds of bugs in SL now, that are totally ignored by LL et al, in favour of new stuff with bugs. Texture loading suddenly seems much much less reliable in the last week or so... Why? Is this human nature, or bad bad bad management at Woob Woob Labs? imho: LL are the Three Stooges of coporate management... Woob woob woob woob °͜°

I use Phoenix, and textures in a sim used to rezz fully very fast. In the last week, I am seeing my own sim textures rezz and stop at blurry, one step before finished... Why is this? If I zoom into them, they usually do rezz, but not always. Since I have been using this Phoenix for two months now, and only have seen the problem in the last week, I assume it's Linden Labs mucking around *again* Woob woob woob woob. ty

Innula, thanks. *VERY* obscure!

How do I detect when an object is attached to an avatar, but NOT during login? Thanks

Kaluura Boa wrote: "In all cases, reading a new notecard line or block of text should be initiated as the very last action in the current event so that the script makes its stuff when it should just go idle otherwise." I would think that this depends on the script and data and what you are doing. But if the script (A) stops after requesting a notecard line, then the next thing to happen would be the entry of the Dataserver event -OR- the completion of the (A) script *followed by* entry to the Dataserver event. I suppose this could be tested. In my case, the amount of processing is pretty small. In any case, I will put my next request at the end of the current event/handler.

To avoid all limitations, I think I am going to use the dataserver to read lines, one at a time. Testing shows you can reliably read lines about 10-20 per second usually, more than enough for my purposes. Also, using dataserver to read lines means notecard size is unlimited *(except 255 limit per line) so QUESTION: Does the Dataserver hang? I can put in a timer to take care of that, but curious if it does. Thanks

Thanks to all for your support in the past. Due to 64KB mono limits (minus code), my object only reports about 25KB of room to save and store notecards contents in lists in the script. I have thought of several ways to overcome this: 1. Have a second small script which only loads each notecard on request from the Main script, then is able to feed one line at a time from the notecard to the Main script on request. 2. Instead of storing the notecard lines in lists in the Main script, just read the lines via the Dataserver as needed. The fastest I would need to retrieve these lines is about: one line every 2 seconds. 3. Have one script for each notecard, with each script loading the notecard contents only once (per script reset) and then able to present one line at a time to the Main script on request. In all cases, the Main script should only have to hold one (or a few) lines of the current notecard, so the 25KB working room is no longer critical. I would appreciate comments on the above options, or any other options you think might be preferable. Thanks!

Okay I see what is going on now. Due to the non-garbage collection, I do not see the memory freed, and when I load the next notecard, I have TWO notecards in memory when that is done, before I wipe the myNewList. In some cases, the two biggest notecards loaded in succession are bigger than the (only) 25K I seem to start with each time (after Reset Scripts). So, I can either shrink my scripts to start with more, or use a separate script to load in the new notecard... Does that sound like a good idea? I suppose if things get Fat, then I can keep the current notecard in one script, and have it serve data to the main script, plus have a 3rd script which loads new notecards. This only works if I get 64K of mono each time, yes? Thanks

1. EOF is always seen, except when the script crashes before EOF due to out-of-memory. 2. I have two lists in use; I fill up myNewList with lines from the desired notecard while preserving myList in case the user decides not to run the new notecard. 3. If the user declines to run the new notecard, I continue where we left off with the current notecard lines. 4. if the user accepts to run the new notecard, I set myList = [ ]; myList = myNewList; myNewList = [ ]; I don't see a way to be able to debug this without forcing garbage collection... Question: If I build myList, then build another list myOtherList, then load myNewList .... Will I *ever* be able to recover the memory taken in the original build of myList? Or does myOtherList block the heap and lock up the memory taken by the original myList ?

Rolig Loon wrote: That should do it, so my guess is that you are looking at the wrong problem. Are you sure that your dataserver event is behaving properly when it senses an EOF? You might be getting an overflow because it keeps reading line after line after line, well past the end of the data on your card. I do an llGetFreeMemory( ); after every line read from the notecard. And when I do the myList = [ ]; the memory is not freed up.

Okay, I am using Dataserver to read lines of notecards, but when I read a different one later on, the old memory has not been freed. How do I release memory from a list? I tried: ... myList = [ ]; Memory does not get freed up....

Aha, beat on it and this time got: Object v1.17: Stack-Heap Collision However, please NOTE: I do NOT always get an error message. Sometimes the script just hangs.

Why? How should I deal with this?

Ah, sorry. I completely misunderstood. Yes, my question way back was does sound queuing work on all pairs, or just the first two. Sounded like you were saying first two only. All else is clear; that was only glitch.

Rolig, so you are saying there is no way to actually butt two sounds up tight, other than the first pair? Have I misunderstood? From then on, it's blind luck? I would think sometimes lag or server-side delays of each a second would totally muck up any attempt to "blink lock" two sounds. If the time delay is a smidgen too short, then you clip off the end of the previous sound, yes? And if it's a smidgen too long, then you get a silent gap? Is there seriously no other way to do this that truly butts sequential sounds together after the first pair? LL are the Three Stooges of coporate management Woob woob woob woob °͜°