Posts filed under ‘Technical’

Rotation pinning on new PhotoStand

You would think that a pose stand is something very simple: you sit on it, move forward and backwards through the list of poses, and little else. Most nice stands also incorporate a rotation feature, so you can adjust the angle of the model on the stand as necessary. And that’s about it, most of the time.

However, some situations require more. Imagine that you are using your run-of-the-mill pose stand at your studio, where you also probably have a backdrop and some other elements and tools. Most likely, you want your models facing you, the photographer, most of the time. For some of the poses, you may want to rotate the stand to one side or the other in search of that perfect angle; you may even rotate it 180 degrees for a back shot. In any case, the “default” position of the stand, the most common one, should be facing you. Bear with me.


22 February 2008 at 2:18 pm Leave a comment

Stuck menus

A few PhotoStage customers have reported recently that, sometimes, the menus get “stuck” after using them for a while. As documented in our FAQ section, this is often caused by Second Life “eating” or losing one of the messages that the different components of PhotoStage use to communicate with each other. Usually, resetting the scripts in the Control Box solves this (see the FAQ page for step-by-step instructions).

However, we have found two cases in which resetting the scripts in the Control Box did not solve the problem. In those cases, the “stuck menus effect” seemed to happen randomly, not related to lag, but apparently related to a particular sim. We have not been able to reproduce this issue at our headquarters in Lady Vale. In one of these cases, a sim restart solved the problem, but not in the other.

Please notice that the stuck menus effect has never been detected on PhotoLite, but since PhotoLite and PhotoStage use the same communications facilities, we wouldn’t be surprised to find it there as well. Also, please bear in mind that using the HUD does not work around the problem.

At this point we have not been able to diagnose the cause of this problem. Due to the apparent randomness of the effect and the fact that it seems to be related to the Second Life infrastructure (it is sim-dependent), we have decided to rewrite the communications facilities of PhotoStage and release an update as soon as possible. The new communications facilities will be more robust and less dependent on Second Life’s ability to deliver every message.

We will let you know as soon as a fix is available. We are working on it now. In the meantime, please accept our apologies, and please contact us if you observe the stuck menus effect. Your feedback will be useful in heping us diagnose the problem.

Thank you!

20 February 2008 at 5:37 pm Leave a comment

No-transfer textures failing to show on the PhotoStage backdrop

We have detected that no-transfer textures fail to show on the PhotoStage backdrop. You can add a no-transfer texture to the backdrop, but when you try to use it by navigating to it using the Previous/Next buttons, the backdrop turns white (or whatever other colour you had it set to) and a script error is shown.

We have traced the cause back to the SVC-368 issue documented in JIRA. It seems that the llSetLinkTexture() function does not work well with no-transfer textures.

The obvious solution is to use transferrable textures with the PhotoStage. We are updating the User’s Manual to reflect this. 

In addition, we will study the feasibility of modifying the PhotoStage backdrops so that they work around the bug. This is not a trivial change to make, and it may take some time. We will announce any progress here. In the meantime, please stick to textures with transfer permissions.

We hope that you understand that this is not an issue with PhotoStage, but a documented error of Second Life.

Oh, and thanks to Corbin Carling for raising this issue with us.

8 February 2008 at 1:00 am 1 comment

After the 1st February blues

Now that the SL glitch that broke the PhotoStage’s scripts has been solved, we can spend some time explaining exactly what happened.

Linden Lab announced an update of the server code on 31st January. This was applied as a rolling restart, which caused no apparent problems other than the sims going offline for a few minutes as it is usual. However, the server update changed something that was not documented, announced or advertised. Before the update, the Description field of any prim could contain many characters, including (why not, one could ask) the character called a pipe “|”. This character is often used by scripters and programmers as a delimiter, i.e. used to separate blocks of text or values from each other. The Description field of prims is also used frequently as a common place where data can be shared by multiple scripts running in a single prim. Finally, I must point out something that is pretty evident, but apparently needs pointing out (you will see why in a minute): when you put some text into the Description field of a prim, you expect it to stay there, unchanged, until you (or somebody else) changes it. This is just common sense.

After the update, things changed. You can still put a pipe character into the Description field of any prim, but that character is automatically and silently converted to a question mark “?”. Imagine that your script puts the text “hello|there” in the Description of a prim; next time you look at it, it will show “hello?there”. As you can imagine, having characters changed by SL under the hood, silently, and without your permission, is not a good thing. Your script relies on finding some text there and, instead, it finds something else. As a consequence, what used to work before doesn’t work now.

I am going into rant mode now.


2 February 2008 at 2:16 pm Leave a comment


Second Life

Second Life and SL are registered trade marks of Linden Research, Inc.