KT Kingsley

I guess this has to be done the old-fashioned way, as in Vertigo and Jaws, with at least some manual input. Fortunately you can script the camera movement, and focusing isn't an issue in SL, meaning you can do away with three or four assistants, leaving you to adjust just the FOV (zoom; camera angle in SL viewers) manually. The smoothest way of doing this that I can see would be to use Quick Preferences in Firestorm, tying the debug setting CameraAngle to a slider with a very fine increment. Unfortunately this control takes up some screen space, so for this shot you'd have to crop the video image to edit it out. By putting the control at the top of the quick preferences window and sliding the rest of it off-screen you could minimise the intrusion. And I guess you'd have to have at least some of the user interface showing, too. And then practice a bit. I can't image the dolly-zoom shots in either Jaws or Vertigo being done in just one take.

As a workaround, my first thought would be to try using the changed event and the CHANGED_REGION flag to trigger the HUD to explicitly remove any RLV restrictions and then detach itself (either via RLV or LSL – or both).

I can rarely resist using if (toggle = !toggle) when appropriate. Also in llList2* selections.

You could replace the active dialog with a new one that just says something like "Menu timeout" and doesn't have a listener associated with a throwaway channel specified in the llDialog function call. While some viewers can enable multiple dialogs from the same object the default setting is for new dialogs to replace any existing dialogs that originate from the same object. And yes, llDialog works like that. It returns the button label clicked by the user as if the user has chatted it on the specified channel. Channel 0 is the public chat channel that everyone hears: it's usual to use a non-zero channel with llDialog so that the command doesn't appear in everyone's chat windows. Note that in your example you call close_menu() immediately after opening the dialog and setting the timer, so there'll never be a chance for a listen event to hear the button command. You only need to close the listener and disable the timer in both the timer event itself and in the listen event when a button command message is received.

It works for me using these scripts, where I've filled in some stuff needed for them to compile and run: string nameTag; default { touch_start(integer total_number) { nameTag = llGetSubString(llGetObjectName(), 0, 6); llRegionSay(-83951,nameTag); llOwnerSay(nameTag); } } and string nameTag; default { state_entry() { llListen(-83951, "", "", ""); nameTag = llGetSubString(llGetObjectName(), 0, 6); } listen(integer chn, string nam, key id, string msg) { llOwnerSay ("msg " + msg); if (chn == -83951 && llGetSubString(msg, 0, 6) == nameTag) { llOwnerSay ("!!!"); } } } The only idea I have is that in your case the first seven characters of both object's names are not identical. (In my example both objects were called "Object".)

Exactly ditto.

Use an if statement to test for link number 1, and if it's so don't do anything. One way would be to put the test at the start of the touch_start event and quit the event, doing nothing, if the link number is 1: if (llDetectedLinkNumber (0) == 1) return; Given that there's also another special case, link 9, the top, maybe some if/else statements might work better for you: if (llDetectedLinkNumber (0) == 1) { return; //do nothing } else if (llDetectedLinkNumber (0) == 9) { //open the box } else { //give a chocolate }

Yeah. Now I've tried it, I can confirm PRIM_PROJECTOR throws a run-time error when used with llGetPrimitiveParams. This is, to me, unexpected behaviour (seeing as how it's documented in the wiki), and probably worth a jira. Unless someone out there knows if or why this implementation hasn't happened.

The function you want is llGet[Link]PrimitiveParams. It goes something like this: list params = llGetPrimitiveParams ([PRIM_PROJECTOR]); params = llListReplaceList (params, [my_new_ambiance], 3, 3); llSetPrimitiveParams (params); Totally untested. Erm, yes. Don't forget to assign the return from llListReplaceList back to the variable params, like I did when I first posted this.

Yes, that effect is what I found with sit TPs where the unsit immediately followed the move. It's been a while since I did one of those, though.

In my experience a delay before unsitting an avatar really does seem to be required in sit teleporters, but not in other situations. Please excuse the derail.

Actually, you can declare a global variable as another global variable provided you do so in the right order: vector Room2 = <88, 59, 441>; vector tpDest = Room2; works – tpDest is assigned the value of Room2, while: vector tpDest = Room2; vector Room2 = <88, 59, 441>; doesn't – it throws a "Name not defined within scope" compiler error.

...

SpaceNavigators are a nice toy in SL, but mainly they make Blender almost useable.

Regarding clothes, you may want to take a look at the plethora of mesh "template" clothes: these are full permission (i.e. you can copy, modify and transfer – sell – them) fully modelled and rigged clothes that you can create your own textures for. They often come with basic textures that'll give you an idea of how it all works and how to get started.

I wonder what the performance hit of two mirrors facing each other would be.

There was a discussion about mirrors at a recent user group meeting. This is Inara Pey's report: https://modemworld.me/2022/03/19/2022-ccug-tpvd-meetings-week-11-summary-mirrors-maybe/.

Just to note, as the OP has found, there's a footnote to the CHANGED_INVENTORY flag on the changed event wiki page that reads "CHANGED_INVENTORY won't be triggered if the inventory change was caused by a script function or a user taking advantage of llAllowInventoryDrop". https://wiki.secondlife.com/wiki/Changed#Footnotes

Does the documentation for the selling script say anything about it sending link messages when a transaction is completed? (Yeah, too much to hope for, I guess.) Maybe just a timer that tested the inventory every minute or so wouldn't be too heavy on the simulator. Or maybe one that speeded up to once every second for a couple of minutes after a touch_start event and then settled back to once a minute.

Here's an example you can try for yourself. Rez a cube and add this script: integer toggle; default { state_entry () { llSetLinkPrimitiveParamsFast (LINK_THIS, [PRIM_TEXTURE, 0, "30223fc4-3bf2-3387-d52f-a4d57bc97e3c", <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0]); } touch_end (integer count) { llSetLinkPrimitiveParamsFast (LINK_THIS, [PRIM_TEXTURE, 0, "30223fc4-3bf2-3387-d52f-a4d57bc97e3c", llList2Vector ([<1.0, 1.0, 0.0>, <0.98, 0.98, 0.0>], toggle = !toggle), ZERO_VECTOR, 0.0]); } } You can see a darker band along the white edge and a light one along the black edge where the graphics system is blending the opposite edges of the texture. Clicking the cube switches the texture repeats between <1.0, 1.0, 0.0> and <0.98, 0.98, 0.0> so you can see the difference.

My first guess is that it's stretching a texture ever so slightly so that there's no bleed-through across opposite edges when it's applied to a prim face.

You can access graphics presets via the screen icon at the right of the top bar, at the bottom right of Preferences/Graphics/General and in the camera control window (Avatar menu, Ctrl+K). Note that Firestorm has a compact version of the camera controls available that doesn't have the presets buttons. Which version you get is determined by the "Use small camera window" setting in Preferences/User Interface/Interface Windows. I don't think the LL viewer has the small camera window option, but the rest of the preset controls are available, presumably located in the equivalent menus and windows.

Autotune is looking pretty good. The only real issue I'm having is with my own avatar's (system body, but not attachments) shadow flickering on and off rapidly, apparently when my FPS starts dropping towards my preferred minimum. One thing I think I'd like to see is a user-configurable hierarchy of graphics features to tinker with to maintain the FPS; for example turning shadows off before reducing draw distance below 64m. And yes, I can see how this could become a bit of a nightmare both to implement and for the user to set up.

I've noticed that parts of my system avatar are appearing deformed. This image of the avatar wearing a skin that reflects the underlying system avatar mesh has the most obvious deformations highlighted: For comparison, this image shows the system avatar UV layout (on which the skin used in the image above is based): The problem appears to persist through viewer relogs, changes of the shape worn and changes of the physics worn. Does anyone have any suggestions as to what's causing this and how it might be fixed? ETA: bleh, well, a cache clear, relog on the SL viewer and relog back on Firestorm seems to have fixed this.

The thing about a HUD or in-world object to control a projector is that while it takes only a single line of script to set the projector parameters, choosing the texture and colour will run to a few hundred lines and require a fairly complex object for the control panel. To make this worthwhile the end result would have to be easier to use than the built-in edit controls. Making this would not be a trivial exercise.