Profaitchikenz Haiku

Are you referring to objects that can change shape using a script that loads different sculpt maps or changes the prim types and parameters to force them into different shapes? If so, then it can't be done with mesh, the basic geometry is set by the uploaded mesh file, and only the scale of it can be changed by a script.

If you can prove to me you have her permission, we can paste her likeness on the centre skittle in the Mock Turtle's skittle alley and we can all take turns trying to knock her down. (Ooo-er, Missus).

Don't rush to accuse all such you-no-see-me types as being griefers. For a lot of them, it's a fun thing, to wander around invisible. I see them as being in the same class of resident as the bloodlines biters, the people who wear exaggerated animal outfits, or the gigants, it's another form of play-acting. As long as they don't *cause* annoyance then they aren't griefing. If they start pushing people around, or blasting sound gestures then that's different. I think an invisible avatar leaving behind a trail of dark footprints slowly fading in their wake would be cool, although too much of it would get irritating.

I can think of two possible causes for this. The first is that messages from some other scripted object such as the skydome you mention are being acted upon by items in your house that listen on the same channels that the skydone or some similar item is using. The other possibility is that you have edited the house and added to or removed items from a linkset, causing the prims in the linkset to change their numbers. This would affect link messages going to specific numbered prims, and could result in them acting on messages that they shouldn't. You say you can "get rid of scripts", which suggests this is the more likely option. If you do decide to get rid of scripts to try and stop this happening, be aware of a couple of things. In a linkset, you may have to inspect the contents of each item in the linkset to find scripts that would be masked when you simply look at the contents of the linkset as a whole. Also, a script which changes a texture on an item in a linkset using llSetLinkPrimitiveParams will also be setting repeats, offsets and rotations for those items, so examine the faces of things like the curtains and sofas and note the settings before removing all the scripts.

For many of the things you have said you want to make, working inworld is preferrable. Unless you have very good plans with dimensions, using an off-world tool will make it hard for you to precisely size up creations to fit into existing spaces. Ground-cover is a case in point, where you always need to find a way to fill the voids left between buildings and terrain because of the rather coarse resolution of the land-tool. The experience of building inworld with prims is unlike most of the off-world building tools, especially Blender, the closest tool I know is Sketchup, which is very intuitive to use, but then suffers from no direct export to SecondLife method. I have used Singularity to export some of my bui;lds to a DAE file and then looked at them in Blender, but I confess I far prefer the experience of building in-world to switch over to using Blender all the time. But it has a thriving community and is probably the best choice for you to start off with. It is possible that learning it from scratch is easier than trying to learn it after using another method for several years. Alternatively, have a look at the prim-to-mesh tools that are available on the marketplace. I use mesh and sculpt makers and am happy with them.

If your viewer has a preferences setting "Rezz objects under the land group where possible", check it. Current group mismatch is the most common reason for failure to place something when you're sure you ought to be able to.

It is sad that Phaze Demesnes is closing, because it wasn't just a very well made sim, it was portraying some of the best magic/parallel world fiction that is out of the ordinary. However, being different in SL doesn't seem to get the traffic numbers one would hope for: SL right now has settled on a few tight genres such as Gor/Steampunk/Urban Crime, and any sim not fitting immediately into one of the obvious categories suffers from lower visitor numbers.

Since you have so many prizes, and future hunts might have a differing number of prozes, I'd suggest you use a pair of lists to keep track of the prizes, list prizeNames = ["prize1", "prize2", ...] list found = [0, 0,...] As each prize is found, you get the element number for it from the names and set the corresponding number in the found list to 1. In the example, the variable thisPrize has the name of the item the player just touched as a string integer ind = llListFindList(prizeNames, [thisPrize]);if( ind != -1) found = llListReplaceList(found, [1], ind, ind); and so finally to text if all prizes have been found integer test = llLIstFindList(found, [0]);if ( test == -1) // there are no unfound prizes left

Attached objects change the way they behave in respponse to certain actions, for example not allowing another avatar to sit on the attachment. I looked a tthis wiki page nnd although your precise behavious isn't described there, the description of no-copy transfers being blocked whilst attached does sound very similar.

One other thing you have to take into account are the two distinct ways in which people move around in SL. A person who uses the camera set back behind them does require extra celing space above and spare space behind them so the camera doesn't clash with walls and other prims, but a person in mouselook all the time does not have this need, and so for them a build closer to actual scale is useable. I am not a mouselook lover at all, but after working closely with a friend for several years who is, I have learned to appreciate the more realistic feel you can get from smaller spaces, and so have modified my camera settings a bit. Just like real life, the sense of space or lack of it around your avatar creates the mood and feel of the building, and has a subtle but distinct effect on the mood of those inside it. A pub (inn, taven) should be snug and cosy, there should be a sense of being really close to the people around you and this works best if they themselves are also tucked up tight into the room. By contrast, a theatre or a dance hall or opera house needs to give the impression of being much larger than the person, and so this is where hieght and extra space around each avatar is important. Avatar sizing is the biggest problem, of course, and you cannot control this. My suggestion here is to build for yourself, and let others of a similar hieght enjoy your builds. Those who are a metre taller that you are either going to have to rescale themselves, or find a different build. If you try building for the tallest avatar likely to visit, you can end up with a building that a typical user finds far too large.

Like Dora says, you can't call a function or initialise globals using expressions, but putting the wallclock call inside state_entry will only cause it to get the wallclock time once and so it won't update. I would put the three variables inside the timer event if they aren't going to be used in any other areas.

Pussycat Catnap wrote: DawnLoria wrote: If it was just a TP to a place then no biggie. I read somewhere that a girl excepted a TP like this and got her inventory and money stripped away . After the jerk ejected her from his location. I don't know how true that is but after that I'm afraid to exept suspicios TPs and any objects/folders. That's impossible. Though it sure makes a good story to tell around a particle fire while sitting on mesh logs. The real reason people get annoyed with random TP offers is the intrusion of spam and the only danger is you might be forced to see blond avatars or furries or The Furmasons are hiring TP bots to lure people to their get-togethers?

I declare two globals string lastAnim="sit";string anim = "my_animation"; in the run_time_permissions event, after ensuring permissions have been granted llStopAnimation(lastAnim);lastAnim=anim;llStartAnimation(lastAnim); and in the changed event part, after having determined it was CHANGED_LINK, key avatar = llAvatarOnSitTarget();if( avatar != NULL_KEY){ // get permissions for anim and start it}else{ llStopAnimation(lastAnim); lastAnim = "sit";} In the scripts I try to ensure that these segments get actioned as soon as possible inside the events, shuffling other bits of code around so that todying up or setting up takes place after the animations have been started or stopped.

I have a friend who was getting long delays of perhaps 10 to 20 seconds after right-clicking on some mesh objects I had positioned before seeing the menu. Before I go down the route of analysing her viewer, machine, operatying system and so on, is this a known problem? I have gone through the wiki list of debug settings and not seen anything that refers to right-click delays. They do not see the problem when touching (left-clicking) anything, but in that case no menu would pop up anyway.

The only thing I can suggest that would save you from having to clear away the whole parcel and re-rezz the house is to go through it prim by prim, clicking on each one, and getting the edit floater, then in the Z field add 10 metres to the position. After it has shot up 10 metres, if there is a duplicate prim that will be left there and can be deleted. Keep working like that until you have a house 10 metres higher than it wants to be, and lower it back down 10 metres. But it sounds an lot of work if nothing in the house is part of a link-set. Speaking as one who has been there himself, I'd suggest turning on auto-reply until you;re done

Since it is a linkset, why not just use message_linked with a specific integer to indicate it is a jets message, and then there's no need to use listeners? The event for link messages will supply the prim number sending the message, plus an integer, a string, and a key, which would allow you to pass in a key for the particles target as well, should that be advantageous.

You are correct, there is no way in LSL to jump to a label or call a procedure specified by the contents of a variable. The simplest way to implement what you want to do is to have a long nested if--- else if... block. Each if clause tests the value of your variable and calls a subroutine. In order to avoid a lengthy process of testing a number for a value from 1 to 100, I would suggest testing it for equal to or greater then 90, equal to or greater than 80 ... calling one of 10 subroutines, which then test the last digit for 0,1,2....

I want the wavy-hands system from Minority Report.

http://www.bbc.co.uk/news/technology-26921743 An interesting article here about the study of violence in players of video games. What caught my eye was Games modified to have counter-intuitive, frustrating controls - leading to feelings of incompetence - produced more aggressive reactions. I'll say no more.

The most common way to handle this is to have the textures which will be displayed on the face already visible to the clients, although on much smaller prims so that it isn't obvious that you are preloading them, Around your giant prim you place several much smaller prims, on which you have already loaded the 14 textures . Then when you command the giant prim to display a new texture, it is only new to the large display face, since it has already been *seen* on one of the smaller prims. However, this mathod may create lag in that each avatar arriving has to load up the 14 textures, instead of one single texture. If these 14 textures are large (1024x1024) then the amount of data to be served out to all the avatars can be a source of lag in itself. If the sequence in which you are going to display the textures is in anyway predictable then you can reduce the lag by showing on a smaller prim the next texture to be displayed. When this texture is itself moved onto the large display, the new next texture to be displayed is then preloaded. If each texture is going to be displayed for a longish (60-seconds+) period before being replaced then I would suggest you only preload one or two textures. If however you want to be flipping between any of the fourteen textures every few seconds, I would sugest you find a way to preload all of them on smaller prims. I'd suggest you use llRegionSayTo if the prim is going to be instructed by another prim not in the linkset, but otherwise, llMessageLinked is about as quick as you're going to get. llShout risks chat-lag delaying the instruction. I would make sure that there is no touch event in the display prim itself, as the number of avatars you expect to be present all touching the prim experimentally to see what happens could build up quite a queue of events to be processed. People forget that in a touch_start/end event, the parameter records the number of touches detected, and it can be greater than 1

I would start by looking at the individual prims that receive the link messages, try to isolate which of then is affected, and then add some debug statements to the message event and preceding where you have a set colour call, to try and narrow it down further.

From my own experiences, a prim has to be of a certain size to seat more than one avatar on it. Once once over this size I have been able to sit two avatars on a long prim both with and without a sit-target and animation. But, it is fiddly and sometimes requires a couple of attempts. The minimum length seems to be 4 metres.

The usual way is to increase the priority of nthe drinking animation from 2 up to 3, or with some aggressive AO's, up to 4. This allows the animation to take priority over the AO whilst it is playng, and the lower priority AO animation resumes when the script stops the drining animation.

Ah, well done Innula, I was trying to get a screenshot of a script error but none of my scripts seem to be faulty at the moment, and as I donlt wear mesh I couldnlt get shots of the triangles either.

I'm not certain that this is a script error as such, since mesh and sculpted items will or shpould render without any script involved. There is a little warning symbol pops up when mesh cannot be rendered properly, which might be confusing you here, it looks similar to the script warning error. 1. Get somebody else to visit you and see if they can see the items you cannot, in case it is a setting in your viewer that is preventing you from seeing the items 2. Try changing outfits, and see if it is all or only some items not rendering. 3. Using the help->About menu option, note which version simulator you are on, then go to other places checking in the other possible sim versions (Le Tigre, Blue Steel, etc) to see if the problem is in all server versions or only one.