Void Singer

3 upper center offset to the right, is my TP hud... just a simple SMALL tool that hold my most imprtant locations with a cycle button to flip through them. much nicer that the screen eating location/favorites bar in V2. next is another simple one, hovertext time for a few key time zones, upper right, sits right below the SL time. and lastly, bottom rigtht, offset a little left to avoid interfering with menus like inventory that often go there... my own littl multi tool, AO, local radar with direction, and chat calculator. all three built and scripted by me.

my experience was that it was never really fixed, it just became less common... but I've had it pretty consistently even with 1.0 ui setting (although it was much milder at that setting)

or, rather than add prims with posebals, you could try nPose, which is a system similar to MLP that allows for multiple sit positions without poseballs.

agreed, and unfortunately, it's about the best we have.... however, there may be some small halep in there... IIRC the attach points are all at the center of the bone or at the joint. that means that either you are automatically where you need to be, or that resizing a zero-alighned & zero_centered attachment point primwill give you both joint centers when you find one. using an alignment texture on two rod prims with a full alpha avatar should show you a precise center position for the joint between them as well

one list that you pull a sub-list from... you can see an example of this in the multipage dialog code I posted on the LSL Library Forum... in essence it takes a single master list and pulls elements from it as needed to make a full page and inserts fwd/rev buttons as needed (it auto wraps the list too) the idea I built from was to keep your main list as static as possible (while still allowing it to be modified) and providing enough flexibility to serve multiple individual avatars on the same channel without needing extra tracking, for features like re-menu (allowing you to pop back to the correct page after a choice is made if desired) as for lso/mono... unless the list is in the hundreds, or your code takes up equivalent space, it probably won't matter for a dialog list, and the consideration should be on other factors such as if it'll travel between regions or (de)rez frequently.

alternatively you could do what many creators already do, and wait for a response, if the response says there's a new version, the item disables everything but the check for a newer version, and the back end sends a newer version to the av automatically..... this way, if something goes wrong with their newer version they can always pull out the old version to get a new copy... of course this only works well for copiable items.

::nods:: that's another factor that can cause that problem... and my understanding is that it may require linden intervention... stopping by one of the tech office hours and mentioning it may help... I'm not sure if they have access or not so if they turn you away don't be too disappointed.

I've tested vehicles on all the current server versions and experienced no crashes.... the only thing I've noticed is a half second rubberband for all physics objects.

the reason you see "imortal" prims now whereas you didn't before is due to a fix for "ghost" prims (non-visible non-returnable), those prims were previously invisible, but are now visible. this was a recent change, but not quite as recent as the magnum release (about one or two weeks behind it). one *may* compound the other, but they are separate bugs, probably made more noticeable by occurring on the same channel

nah, you had it right, it's all good... that was all my f*** up, and no hard feeling on my part... I shouldn't browse half asleep, you have my sincere apologies. I actually deserved a smack for that one

I jumped the gun while skimming, and misdirected that at you... sorry please pretend that I directed that at the right person while I wipe the egg of my face and go sit in the corner =X

please note that you should NOT delete the whole folder before moving your chat logs to another location if you care to save them.... otherwise they will be lost. (I really wish people would stop suggesting that without warning people as logs can contain important information)

clear cache, and relog to a different region

skip the novatech scanner and just use a simple listen script such as... integer WEAPON_CHANNEL = -12020423;default{ state_entry(){ llListen( WEAPON_CHANNEL, "", "", "" ); } listen( integer vIntChn, string vStrNom, key vKeySrc, string vStrMsg ){ llOwnerSay( vStrNom + " said:\n" + vStrMsg ); }}

if suddenly things are different, then something has changed... could be the region you are in is having problems, could be congestion or ISP problems, could be you are running something different on your computer (like a scheduled virus scan)... the first you can check by going to different regions, the second you can check by doing an online linespeed and ping test, and the third you should easily be able to see by looking at your running programs.

openSUSE 11.4 (latest version)... a flavor of Linux

Ishtara Rothschild wrote: ETA: I'm kidding of course. But I'm seriously glad that games like WoW exist. Otherwise those prisoners would be slaving away in Second Life and steal the income of disabled and/or batshirt crazy Western welfare cases. like you? I ask because I find the statement rather telling either way.... either you speak from personal experience (in which case you really shouldn't be so hard on yourself), or you believe you are some sort of special exception to your stated rule who is better than all the rest (which exposes a prejudice and presumption of egomaniacal proportions). neither option reflects well.

this usually happens when you have a linden plant included in the items that were taken... you'll need to find an area where you can create linden plants to re rez the build, which most sandboxes do not enable. someone should be along shortly to tell you where you can do that, I don't remember offhand.

the script in question isn;t bad in and of itself, but it uses the prim description to hold a bunch of information that it doesn't need and store it in a region relative way that requires it to be reset every time the build is moved, and can in some cases overflow the description causing breakage. it does have some features that people enjoy like announcements and sounds which can be nice. newer scripts are written to be relative to the doors position, do not need to store external settings, and can be moved with the build without the user needing to do anything, saving endless hassles with users breaking it or needing to reset

there's a multitude of problems you might encounter with that script... temp rez objects retain a countdown when taken... if you rez the bullet and drop the script in, it starts counting down immediately, so you need to take it to inventory immediately. also items that are temp when rezzed can get queued. velocity can and probably should be set by the bullet rezzor ('m assing some sort of gun) if such is used, and you must be sure to set it's proper rotation. if not, llSetForce is probably preferable to llApplyImpulse, and you'll need to rework it so that it sets a correct rotation (else it will always fire in the same direction) die at edge is always true when rezzed by script, so probably unneeded the timer is probably overkill, max lifetime firing straight up from the ground is 60 sec (temp on rez limit) MONO rezzed script hay be subject to queuing so use LSO functions slow down the time to insert a script, so if you need high response times, it's actually better to insert all function code into the events, same for global variables. none of those would cause the problem you are seeing though.... the only two ways I can see that you'd fail to get the region say but get an ownersay on the line before are if the object is no longer in your region (crossed into another) or your listening script is not set up to receive the message properly (wrong channel or filtered incorrectly)

google could probably as easily duplicate their work and compete directly for a much lower cost than aquisition, facebook wouldn't see a value add, and it's too costly to just sink it as competition, especially considering they don't do much special so there's nothing to stop somone else providing the same service.... twitters only saving grace is that it's the established provider of it's type and no longer small enough to be worth buying out of existence

depends entirely on the script, and how the door was built... but the door should NEVER be the root prim. almost all single prim door scripts allow them to be linked as a child prim, almost no multiprim door scripts allow them to be linked. there is an example of a simple hinge script in the script library that follow those above stated principles in the LSL Library forum as stated above, you don't NEED to link things together to package them together... you can use coalesced objects (select all parts then take) or use a box rezzor (easier for customers to handle) to package multi object builds together. ETA: please for the love of all that's holy (and a reduction in problems and complaints from your users) do not use the "Timeless" door script... if nothing else, have some one rewrite it for you, so that it does not have all the reset logic that is not needed.

two ways 1) move the script to the child prim you want it to target 2) check which prim was touched with llDetectedLinkNumber #1 has the benefit of only showing the touch cursor for the prim you want to actively receive touches, the drawback is that the script is moved out of the root, so more work to edit #2 has the benefit of staying in the root prim (and could potentially handle multiple such button prims), but has the drawback that the whole object will show the touch cursor.

in lsl, yes list processing is a slow operation, but the tree structure itself is still more efficient, AND faster (not necessarily the same things, and I didn't say the latter till now). not all data requires a list find, and some could require extended string processing which is even slower. of course we're talking microseconds difference even in LSO. considering that I do active searches with conversion on lists of ~600 long string elements up to 1/sec without any noticeable effects, I doubt it'll make a noticeable difference. On the plus side of that tradeoff you get the ability to to separate the command path out, and even manipulate it on the fly, which makes the code more reusable. it also prevents duplication errors, compared to the if only version. that said, for 4 item text commands, it really isn't going to make a difference one can notice no matter how it's written. but the op wanted to know the difference between the structures.

just pointing you to the quickest and most complete resource with the most competent people