Void Singer

just because you tell people to change their password every week does not mean they do, or do it inteligentlly. some will use the same password for everything... bad idea....only do that for things you don't care about (like throwaway services that require you to sign up for something you'll only ever use once) important things, like anything with the ability to collect money or spend your money, gets it's own password. although if it's happened twice in one week to this friend, my suspicion is that A) someone has access to their computer (either in RL, or via a keyloger or other trojan software, especially if they have other recent accounts broken into) or B) they're full of it and really are spamming this crap to get a few L$ (you'd be suprised how many people do that voluntarily)

if Roligs suggestion doenst work, it might help if we know what you are trying to accomplish, and what attach point it needs to work from, and exactly how it's failing. ... and you may want to use PSYS_PART_FOLLOW_SRC_MASK

by shutting it down the first time debit permissions disappear, it prevents further abouse of both you and other customer who might try to use it. the only way for an object to lose debit permissions at this time is for an owner to manually revoke those permissions, using one of the few viewers that will let you. which means they'd have been present when they did it. there is a vague chance that something could be screwed up by LL or it have been a mistake by the owner. you don't have to automatically request permissions in on_rez, or default state_entry, you can simple wait for the owner to take an action like touching the object. it just sits and waits until then. that way it's a fail safe in case the script does get reset somehow, without the owner present... which shouldn't happen either, since only manual and scripted resets (from within the same object) should reset an active script. the only time a script should reset is when a script within the prim tells the script to, or the owner, or someone with edit rights for the owners things resets it... ps, I should have said 3 messages, because one shouldn't assume some disaster by LL didn't cause it... messages go to customer, owner, and wharehouser (that's you if it's a resale vendor, or you are getting a cut. otherwise, not needed)

I really hate it when the things I eat suddenly reappear... ohhhhh, you meant *FOOT* alphas....

why would you want to trigger a check for debit permissions every day? instead, check before the object does anything.... if (llGetPermissions() & PERMISSION_DEBIT){ //-- do stuff }else{ //-- report problem to payee and move to a different state } in that other state you could request debit permissions again whenever the owner took some action. I assume this is some kind of affiliate vendor system? my suggestion would be for it to check that it can debit when it recieves payment from someone, if it can't, have it fire off two messages... one to you that says it's unable to request an item for delivery because the owner revoked debit permissions, and one to the person paying that says it can't retireve the item and is unable to refund their money because the owner revoked premissions. it should also tell them to contact the owner, or file a fraud report with LL. ETA: because debit permissions should NEVER go away unless there is an owner change, so fraud is highly likely... and this way A) if it was an accident, the owner can take care of it, and B) it makes it harder for the reseller to keep ripping you or customers off, and C) if it happens multiple times there's two people to file a fraud report for each instance of it happening, and very good odds that LL can suspend that account quickly.

softness: how much it "wave" it can have in the middle, opposite of stifness. gravity: the ammount and direction the gravity tends to pull/push on it (expressed as region +/- z) drag: how much to slow movements (limits "wagging") wind: multiplier to be affected by region wind (which is a region x/y force) tension: how strongly it reacts to movement force x/y/z: the *region relative gravity to apply in a particular direction. ETA: *sorry, force is region relative, not prim or object relative, correted above

the fact that you offered a way to subvert the permissions system when asked about downloading a sculpt makes me question your ethics, AND provides and all too simple explanation of why your wouldn't care to protect your own. because you "just didn't feel like paying for that", confirms to me that you don't take others rights seriously.

And I might as well give you the simplest script for a hinge..... integer gFltDeg = 90; //-- rotation in degrees.rotation gRotRad; //-- rotation in radians.default{ state_entry(){ gRotRad = llEuler2Rot( <0.0, 0.0, gFltDeg * DEG_TO_RAD> ); } touch_end( integer vIntTch ){ llSetLocalRot( (gRotRad = ZERO_ROTATION / gRotRad) * llGetLocalRot() ); }} stretch doors on the x axis, stretch cabinents/lids on the y axis, z axis is always height. settings always: box, path cut 0.5 +/- 0.125 (AKA [0.375/0.625]) works at any angle, linked or not, flip the object in edit if you need a hinge that goes the opposite way caveat: door should be closed when the script is added or if you manually reset the script. ETA: might help if I consistently named variables. ETA: might help even more if I actually tested it instead of trying to write from memory... fixed

they made the interface HUGE so you would look smaller on the screen?

1. Does llResetScript( ) always cause state_entry to be run? if it is present in the defalt state, yes, otherwise the default state is entered 2. If so, do I need to read the Agent notecard anywhere but state_entry? only if you reset... but that's kinda sloppy... you could have it only read once and never again, then you wouldn't need to check for changed or on_rez, alternatively, you could just check in one of those two events... 3. out of curiousity, does a "script reset" trigger on_rez? no, it's the same behavior as if you had just compiled the script, all variables start fresh, all events are cleared, the default state is entered and state_entry fires if present for that state 4. In a no-mod object, can the new owner reset scripts? What should I do then? there are ways that it can be done, or even happen because of borkage... do not rely on it for security... you best bet is to have the script try to go back to what it was doing normally, or be broken. 5. the "Agent" notecard will always be there; this is a no-mod object. Do I still need to check and read after fixing items 1-3 above? Can the Agent notecard be deleted from a no-mod object? yes... there is a work around to prevent that, but it relies on a bug in jira that is very likely to be fixed. 6. do I really need anything other than state_entry? Is state_entry called each time the vendor is rezzed from inventory? no, state entry is only run when the state is entered... right after compile, reset, or state change only.... on_rez is the event that fires on every rez. 7. will changed be triggered if the new owner drags the vendor across a parcel boundary? Unlikely, but I think I need to handle that... CHANGED_REGION will fire in the changed event... if you only filter for other events, then you shouldn't have to worry about any other events... for instance if (CHANGED_OWNER & vBitChg){ would only be trigged by the changed owner event

I think there are elements of truth in both Lexie's and Kidd's statements, and not to knock either, I don't think eiter draws an entirely accurate picture... were the old forums heavily given to long (and frequently wandering) discussions? yup was the separation of "answers" a move that made it easier to narrow the focus of threads? uh huh but neither addresses the history behind the moves... the old forums were poorly layed out, and only accessible to payment info on file members as a legacy of when there were no free accounts. there had been multiple attacks of the software, and extremely poor integration as well as poor managment and patchwork fixes... Answers was being touted as the new way to do things, sleek modern and in theory, cutting out the "noise" of the original forums, with better integration, increased participation, and management by a third party company.... unfortunately it was deficient in several ways, and some very vocal and even well paying clients made a point to LL that the "noise" was actually "community", and the "modern" methods weren't allowing for support in extended matters. they demanded a place for those things to continue... LL decided that it worth their while to consider those demands and recreated most of the original forums as separate to to answers, (IMO) to allow them to exmplify one aspect to corporate backers, while downplaying the other, while taking advantage of the ability to move extended conversations off the main radar. the software, however, was never intended for the formats or environments it was being put to use for (as a publice solution it was immature, and it was painfully obvious how much it was lacking, and that only increased over the course of the contract year.... because of the abrupt manner and poor performance of that platform, many productive members moved off to other places where the featureset was more useable. enter lithium, which, while still not as mature as some solutions, is a far cry and improvement from the previous jive software. but rather than completely dump the forums as they had tried before, and had received major outcry over, instead they ported over both sections as before, and you saw a quiet effort to eliminate some of the "noise" again.... and since at the heart of that "noise" is a strong sense of vocal community, there was outcry again, although more limited because the entire forums weren't being abandoned at once.... TL;DR? while I agree with parts of what Lexie and Kidd said, IMO it boils down to, LL is managerially attached to the "answers" methodology, but can't seem to get rid of the forum methodology no matter how hard they try, and they desperately want to divorce one from the other for reasons of marketing and publicity.

A tweak to the preference page links would be most welcome, and the main tabs to show which was selected wouldn't be bad either =)

Abu Nasu wrote: Ah, but the real strangness is that this is the second time typing this post. Apparently, while typing a sentence or two about blaming quantum mechanics, I crossed the event horizon that causes my computer to reset. Hmmm... I don't think you crossed the event horizon (I still see you), but perhaps your mixed metaphor caused the waveform to expand to include your computer, but then it collapsed again because you were there to observe it.

if you do not have any other accounts, or do not care if they are known, then the only "risk" is that someone would be able to know your IP address. this is no different than the risk of cookies tracking your web browsing habits or invisible single pixel images in web pages and forums linked to outside servers grabbing your IP Address, with the exception that they can link the IP Address (which is something that will likely change from time to time) to your avatar account. if those risks are acceptable, or unimportant to you, flip your media on and enjoy =)

you would need to contact LL directly for any Account bans, although if it was just a land ban, that's up to the land owner. unfortunately after 2-3 years of inactivity, your account has probably been emptied, and retired... you would need to contact LL about that as well, but you can file a ticket for that via the help menu above then going to "contact support" on the right hand side

wikipedia (http://en.wikipedia.org/wiki/Mainland) does a fair job of explaining why it is Mainland, and not mainlands... but it mostly boils down to being a title, rather than a contraction of words.

yes, but only scripts that take control will remain enabled when you fly back down.... there is a separate region setting for turning off all scripts, which goes to all heights

I'm assuming that you ARE flying up when you do this, and then suddenly the HUD starts working again? this means you are in a no script area, which ends ~100m above the ground of the parcel with "no-script" set... and if go to a different parcel you shouldn't have any problems. you can tell this is set from the icon to the right the parcel name at the top of the screen (its a smal scroll icon with a red circle and line symbol at the bottom)... if you mouseover the symbol it will tell you it's meaning

who needs comments when you can reply normally?

you're right of course, I had PUT on the brain (which is why it seemed off to me)... my bad.

while I can't give you a guaranteed fix, I can tell you that you are not the only one having this problem.... please go here log in and select watch to get e-mail updates on this problem (and maybe someone will come up with a solution) in the mean time, if you have been editing your profile from within the SL viewer, instead log into to your profile page directly in an external browser, and edit it that way instead.... if you have been updating it from the web page, then use the veiwer instead. if neither of those help, you can try installing a Third Party Viewer (please be sure to set a differen cache location for each viewer and restarting that viewer before logging in) and edit your profile from that viewer, using the old style profile editor (this method has been know to work, and has not failed so far)

having "Payment Info On File" means you are Account Verified, which will let you acces adult search, and adult land that is NOT set to restrict access to Age Verified accounts... (this may still be buggy, and you may need to USE your payment method once before it will update... updates can take as much as 24hrs to show up. if it takes more, file a support ticket.) to Age Verify an accunt, please see the instructions here [yes the words are confusingly similar, especially whith the addition of "Verified" everywhere, and even the LL article seems to use the wrong words in some places, but they are two separate things. AGE verification requires some form of legal identification. a credit card is not a for m of legal identification]

you using a post request to feed a form?... that doesn't seem right... but at any rate I see that your body is not escaped with llEscapeURL, you also have a seach indicator in your address but no search string. if encoding the body doesn't work, and and ditching the search string doesn't help, try reformatting your call as a get, change the mimetype back to text, and move the encoded body into the url line (after you put back the search indicator) and then process the seach string on the other end instead of the body....

actually there is one other way to do entirely inworld interregion communications.... although it can get pretty complex.... http with e-mail moderated DDNS.... it works like this: you have a single prim that acts as a DDNS server... it proccess emails, and returns the desired address via http... when a nodes http address changes, the node fires a message via email to the DDNS prim. the DDNS sends confirmation back via http, and if successful, updates the nodes address. other objects can request a node via email, and the DDNS server will try to send the information back to the requester (using a return address specified in the request, could be email, http, or even region say), and the requester SHOULD store that, and continu using it until it fails, before requesting an update. you can add some more checks in there to report region outages, or even set up your own network of routed messages.

I had a similar problem recently... setting the next owner permissions in inventory cleared it up so that the the UPLoaded texture showed up properly... other rules: if the texture is (no transfer) you can only apply that texture by dragging to each face, or by script using llSetTexture (if the texture is in that prims contents) if the texture is (no copy) you can only apply the texture by placing it in the prims contents, and using a script that calls llSetTexture scripts cannot use any other texture setting calls except llSetTexture for (no copy) or (no transfer) textures... llLink* calls that refer to a texture in prim contents whith one of those two settings will fail (the script will give an error, that the items is not copiable/transferable, and state that it cannot find the texture) even if you are trying to apply the texture to the prim that the texture is in.