Delivered

January 12, 2010

After what seems to be forever, I finally got a working example of having a product delivered to me. I’ve been going through a bit tonight with the common bugs.

The first is an issue that I keep running into with data comming from websites. Most websites and form data will encode the space character as a plus sign “+”. The method to unescape encoded data in LSL scripts does not handle this plus sign, so I’ll often get results with a lot of plus signs between words instead of spaces. I’ve reported this as a bug, so feel free to vote for [SVC-4900] – llUnescapeURL does not unescape + character. To get around this problem, I first carry out string replacement before I unescape the data.

One of my big pet peeves with LSL is the lack of a string replacement method such as llReplaceString(text, pattern, replacement). Please vote on [SVC-1085] Provide a string replacement function in LSL. I’m still a bit shocked that so many years have gone on to this seemingly simple request. I’ve worked with many programming languages both compiled and simple scripts. I have never known any to lack such a fundamental feature until I started working with LSL. To work around this problem, a lot of folks created different methods to simulate string replacement. The main replacement function used uses lists, and ends up using quite a bit of memory. However, it is the quickest way.

Now that I have a delivery system, I need to work on streamlining it to cut down on memory, speed, and complexity while improving security.

posted by Dedric Mauriac on Applewood using a blogHUD : [blogHUD permalink]


The Comment Box

January 10, 2010

The comment box was perhaps one of my first big projects in Second Life. The earliest copy that I have in my inventory is from January 1st, 2006. I was making something that could hold notes from visitors and let people see the titles.

Over the years, the comment box has had many changes and updates. Zakk Starr asked me if I had any updates since version 1.9 that he got a few years ago. I handed him a copy of 1.13. I was curious myself and took a look at the newer version.

Oddly enough, I was unfamiliar with a ton of new features that I had put into it. This feeling is the same with most projects that I work on in real life and the virtual world. I move onto so many things very quickly that I forget what I have done.

It’s now smaller in height, but anyone can resize it. The newest model only uses 3 prims instead of 7. Two of them are sculpties. You can choose different textures for the box itself that change both the text and color. A technique has been used so that each individual texture actually contains 16 images, so there is one texture for each color, but all images have the same text. There is only 1 script instead of four. Scripts are compiled in mono. You can adjust privacy settings so that people may or may not see titles of note cards, or get the notecard itself. An access list allows you to control who else may adjust the settings on the comment box as well. Improvement in determining who dropped in a note card, rather than looking at the creator of the note card alone. The owner is sent an instant message as new notes are dropped along with the name of the person, note, and a slurl.

The comment box has come a long way since it’s inception. Previous the the comment box, there was an art easil that I made to display my real life artwork. The earliest copy that I can find of it is version 1.3 from December 31st. I’m sure I made a few before that. The easil is closely related due to how it was able to read the information from note cards and images, display that information as hovertext, and give out note cards. It also cycled through the paintings on it’s own.

posted by Dedric Mauriac on Applewood using a blogHUD : [blogHUD permalink]


Reporting inventory

January 10, 2010

I’ve pretty much got the reporting jobs working with minimal problems in development. The majority of the work was simply copying code from the ping scripts.

I’ve also changed the code a bit so that if someone changed the name of the server, or it’s location, then they could initiate a report request to have that updated. Otherwise, they would need to wait at most, 24 hours for the dropbox to ping the server on its own.

I wanted to do the same for a ping command, since it would require less resources. It appears that the headers that I’m receiving back from requests to in-world objects dont’ include all (or any) of the information that llHTTPRequest provides. The most that it provides is a status code, which I use heavily. The alternative would be to have the body of html returned to include that information along with it.

Delivering inventory is the next phase. I’ve got plenty of infrastructure laid out, but there is plenty more logic that goes along with it. First, I need to look up all dropboxes that contain the item. Then I look to see which drop boxes have reported since the last failure, or failed delivery the least number of times. Part of this is redundancy so that if a region goes down, the delivery queue will attempt to deliver the same product from another location.

I think for today, I’ve gotten plenty of ideas worked out and operational. Tomorrow will give me plenty of time to proceed with the deliveries. Once they are ready, I can then integrate that into my mini countdown timer for trial versions to be distributed for those who ask for them.

posted by Dedric Mauriac on Applewood using a blogHUD : [blogHUD permalink]


Script Time

January 4, 2010


I was trying to determine how much of a performance hit my timers were going to put on the server based on the new functionality that I added to them this weekend. Refreshing the list, they are around 0.003 to 0.006 miliseconds. Every now and then, I’ll see one that takes around 0.010 miliseconds. The timers on the regions debug window really has me confused. It’s always been a bit of a mystery. I think I may have an idea though. The time is more or less, the amount of time that the scripts took with the last pass of execution. Each time the simulator grants execution time to the script (an itteration), it records how much time the script actually took to do it’s magic. Within 1 second, a script may get many, many times to execute. It is only the last itteration that is displayed when showing the Top Scripts dialog. I think it would be more beneficial however, if we could see the total or average number of miliseconds that a script has used over the past second or minute. It is hard to judge a scripts effect on a simulator by looking at the last itterations execution time alone.
posted by Dedric Mauriac on Nowhereville using a blogHUD : [blogHUD permalink]


Emotional HUD Trial

December 31, 2009


I decided to create a free trial version of the Emotional HUD and distribute it thorugh my Subscribe-o-matic. With 352 subscribers, I am hoping that a few may actually find a benefit to trying out the product. The trial is set to expires on the 7th of January. I think this “try before you buy” idea may be a good way to get products out to people who would otherwise pass them up. With expirations hard-coded into the scripts, I would need to keep updating the code. It would be preferrable if there was a licensing scheme online so that each person could have a 7 day trial from the first day they rez an object, and to prevent the object from working even if the rez it again after 14 days.
posted by Dedric Mauriac on Woodbridge using a blogHUD : [blogHUD permalink]


Emotions With Less Effort

December 31, 2009


I took a look at the Emotional HUD and started working on an update. The first thing to do was to compile all the scripts in Mono. This decreased the time from an average of 0.027 down to 0.021. It’s about a 22% increase in performance. I went ahead and started using UV touch mapping to detect which picture the end-user clicked. This allowed me to remove 5 prims as well as 5 scripts. I also moved all of the touch commands from the pictures and arrows into the root prim, allowing me to remove two additional scripts (back/next). The overall performance is now setting at an average of 0.011 (almost 60% increase in performance), with less prims (7 prims instead of 12). There are additional features comming to LSL script that would help me out in reducing the overall number of scripts used – specifically llSetLinkPrimitiveParams and the new properties for PRIM_TEXT (SVC-5168). Still, an object only using 0.011 is very light weight. I may eventually change the look of the object as well. Currently it’s a pretty significan’t size as a HUD attachment. Anyone can resize it, but I’m thinking more or less a way to make it easier to use in general.
posted by Dedric Mauriac on Nowhereville using a blogHUD : [blogHUD permalink]


Pages on a prim

December 27, 2009


I’ve got my little experiment setup to do the following. Touch a prim. You get a dialog asking which page you want to change (1 to 4). After choosing the page, you are asked to enter a URL. The url is sent to http://is.gd/ to be shortoned to a 5 character code. Afterwards the four codes (1 for each page) is sent to a server that I have on my local network which generates a frameset of 4 pages. Those four pages are shown in-world, but only portions of the texture. It’s nice how it works out, but resource intensive on the client. I’ve already crashed once when I tried it with 9 pages and 3072×3072 resolution. The SL viewer UI only allows me to go up to 1024×1024, but scripts are not limited. Pages with a lot of content seem to take longer to display as well.
posted by Dedric Mauriac on Nowhereville using a blogHUD : [blogHUD permalink]


%d bloggers like this: