Void Singer

it happens much less (almost never) if the TP spot is a bit above the ground or other surfaces, and consistently if it's just below them. I like to cheat when making landmarks, and stick a small prim under me to stand on (or just fly up 1m) before creating the landmark... this way you get a slight drop when coming in

see: Can't Logon at work with Websense of for a shorter answer, don't... just don't.

shape helps too, sleds work better than boxes for instance

probably because as chosen likes to point out, there is no such thing as an alpha "layer" =) ok, that was just for fun, it's because applications treat transparency as being part of the layer. if one pixel has even partial transparency, the whole thing has an alpha channel. so if you started with a transparent back ground and missed doing a 100% fill you've got alpha when you export.

no, not really. you can always RIC it, and put in a note asking the moderator to close it, but it's rare for that to happen. reason, just because you are done with it doesn't mean someone else might not have a similar issue, or have details to add

but everone still uses them... the only thing missng form the official ones is looking back at old stats for comparison, and some stats that are built from averaged inwolrd testing of limited regions.... it's helpful to know the source of the stats.

nothing to to do with image format (all formats are converted to jp2) and everything to do with partial transparency. ETA: Luc beat me to it

I like it

Vista32 can only use 4Gb max of physical ram even if you enable 4gt. the HD6670 actually seems to compare fairly well with the GTS 450, edging a little behind... should be able to get high out of it, maybe even ultra, but doubtful of things like shadows. honestly I don't see anything in there that stands out, unless it's just particular region(s) that the problem is in.... performance of course will NEVER be as good as any 3d game on the market, at least not on max settings.

personally I never use the function... the code tends to be a bit clunky with it, especially if you have need for more than one. When I do close listens I use a state change, even if all that state does is jump back to the previous state (sometimes a script reset, but that's kind clunky too) as to which to aim for ::shrugs:: depends on what you are doing... if it has to accept commands frequently or on demand from something other than an av you're pretty much stuck with an open listen. there are a few hack around to avoid it, but some of those (like polling properties) are uglier than just leaving it open and filtering tightly. I do recommend one over many though

it's more susceptible to interruption, slower to work, but I can't say for sure whether it's more or less work for the region on average (though an educated guess says yes it will be), but unless you are using it with lazy loading, then it will definitely be more work over time (repeated calls to get the same information) lazy loading would be where you save the data you've called already, but only call for it as you need it.

Picard approves of Worf's choice to accept discommodation.... I said, I'm just going to sniff around a bit this is an intervention bob, you are a dog, you are supposed to sniff let me introduce you to the board AND your new job.... This is my first meeting, hi my name is bob and I'm a people pleaser (nice to meet you bob) and now I'd like everyone to meet the new top dog.... introducing the sheik of Lupindia (and his harem...) speed dating for dogs ... I could go on... but why?

ah the joys of lowered expectations...

in that use case I would say definitely yes. I fit paired lists of 500 each of keys and integers safely into a mono script, so that should be a mostly safe target. (check my wiki page for the recently updated low spam greeter which has that as a preset and also dynamically adjust memory limits for the list)

posJump is warpPos on steroids.... it's faster, smaller, and suffers less limitations

Eve Neutron wrote: 2. use a negative channel of course. [...] 4. dont forget to use llRegionSay on the hud, because you want to be able to control it from far. @ #2, this advice isn't nearly as useful as it used to be... this used to be to avoid avatars chatting one the same channels, but now avatars can (via llTextBox), it's also bad if you want the hud to be optional @ #4 as noted above "region say" is limited to the source region, and controlling an item from afar is not always a desirable goal (for instance, attachments and vehicles)

you can, but to do it that way you'd need to save the toucher and the time (rather than reset it), and then compare current time to that touchers saved time. unless the item is likely to be under heavy use by people other than the person calling the held touch, it's not likely to be interrupted. I most often use it for configuration type menus, for instance door locks, where a normal touch opens or closes it, and the held touch locks it gives options to a limited access group... the other use case that I often implement it for is to prevent accidental clicks doing things that a use might not intend (such as killing the object, or opening a menu they don't care about)

both words in my name are popular for use, so I always get hits for things like bands (singer) and SF (void)... most of my normal activities are out there for this name, particularly wiki contributions... I only found one item about me but not by me on my last search... someone's flickr shot of my creepy girl av, this time around I found one more... apparently someone added all my wiki scripts to a script database (they credited my name and kept the license text, so all good there). interestingly enough, there's never any reference to my RL, nor RL photo (which are on the web in relation to my name here, but only in exactly 1 place, and that's pretty limited info). which is exactly how I planned it, since I use various SN's to separate areas of my life... nice to know it's working

:: offers a better metric :: instead of judging negativity by the content of posts, or even the number, judge them by how quickly they are created... then, things are only bad when the negatives come in fast an furious, and pretty good when new ones come in at an average rate

what's funny is how everything DM touches turns to crap.... it's the sensationalism and crudity they bring to any topic. there are some general ranges for what people perceive as markers of health... evenness, perk, scale relative to body mass, and age appropriateness (hint: 19yo perky breasts are pleasing on a 19yo, but would be very jarring to look at on a 90yo grandmother hunched over a walker). within those ranges, personal taste takes over (and sometimes exceeds those ranges for small percentage of people).

that's exactly what it is.... however many anonymizer addresses are also marked as problem addresses. My advice is to avoid like the plague anyone or any location that relies on ip matching alone to determine troublesome residents... it might be a different story if one of you had done something wrong, but banning people for having the same IP address alone is just plain stupid.

ETA @ Peggy: normally I'd be more direct, but the direct topic got axed because it bordered on violation of forum rules, so instead I was trying to direct you to where to find information and decide for yourself

well, not all of us are "nasty".... and maybe other "nasty" people would want to join too?

touch_start and touch_end, reset the time in the first, check it in the second, if it's over your limit, it's a held click, otherwise, treat it as a normal click. I don't recommend using double click logic because the viewer intercepts double click if the user has "double click to: [Teleport | Navigate to]" set in their preferences

main considerations for open listens: Avoid them when it's possible (Often not for command menus from huds) Never use PUBLIC_CHANNEL (zero), or DEBUG_CHANNEL (21474836487) Always filter as tightly as possible, in the llListen call if you can, or in the listen event for things you can't Try to pick an unused channel, using a mostly unique one based on the Object or Owner key may prevent collisions (may not be possible for commands that need to be enterable from user chat as well) you can filter to only the owner AND owners objects inside the listen event if you check the object owners key against the owners key with if (llGetOwnersKey( source_key ) == llGetOwner(){ this works because avatars own themselves there is some debate as to whether llRegionSay is more efficient, in some cases it may be in other it may not, but llRegionSayTo is definitely more efficient, but requires the target key and only works within the same region. an easy way to get that key is to have the hud listen for a static one word message from the item, check that it belongs to the same owner and store the key of that item.