Jump to content

Innula Zenovka

Advisor
  • Posts

    10,145
  • Joined

  • Last visited

Everything posted by Innula Zenovka

  1. When I give someone a script that requests debit permissions, I give it them full perms, and explain to them what the permissions request is about and why it's needed. But yes, normally I'd get the permissions requests out of the way first, in state default, before the script can actually sell anything, but this was intended simply as a fragment to demonstrate my suggestion.
  2. How about turning it round? integer iSalePrice = 10; default { state_entry() { llSetPayPrice(PAY_HIDE,[iSalePrice]); llRequestPermissions(llGetOwner(),PERMISSION_DEBIT); } on_rez(integer start_param) { llRequestPermissions(llGetOwner(),PERMISSION_DEBIT); } money(key giver, integer amount) { if(!llSameGroup(giver) || iSalePrice != amount){ if(llGetPermissions()& PERMISSION_DEBIT){ if(!llSameGroup(giver)){ llRegionSayTo(giver,0,"Sorry, "+llGetDisplayName(giver)+" but you're not wearing the right group tag"); llTransferLindenDollars(giver,amount); } else if (iSalePrice != amount){ llRegionSayTo(giver,0,"Sorry, "+llGetDisplayName(giver)+" but you've somehow given me the wrong amount, which suggests to me you're using a modified viewer for fraudulent purposes, so I'm keeping it unless you can explain to my owner, "+llGetUsername(llGetOwner())+", why they should return your money."); } } } else { llGiveInventory(giver,llGetInventoryName(INVENTORY_OBJECT,0)); } } }
  3. The mood changes over time, I think. I post full scripts when I think that's most useful, but if somebody seems genuinely interested in learning, I often prefer to help them with advice on their specific question, and let them have the satisfaction of making the method work in their script -- I don't want to take away that feeling of achievement when they finally understand and get the thing to work. I'm delighted to help people with their scripting if they're trying to learn or having difficulties with something and I can help, but we've certainly had periods in the past when some people clearly kept on accepting paid commissions that were well beyond their capabilities and then relied on the forum to bail them out.
  4. Sorry, I gave you a code fragment, thinking that you would know how to use it. I'll explain in more detail. The attach event fires when an attachment is added or removed. When it fires, it returns the uuid of the avatar who has just attached the object. When detached it returns NULL_KEY (a long string of zeros). What my code says, in effect, is "as soon as someone adds/wears the HUD, request their permission to animate them, and then you can stop worrying about it". string strAnim; default { state_entry() { strAnim = llGetInventoryName(INVENTORY_ANIMATION,0);//get the name of the animation if(llGetAttached()){ llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION); } } attach(key id) { if(id){//if someone has just attached the HUD, ask for permission to animate them llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION); } } changed(integer change) { if(change & CHANGED_INVENTORY){//the contents of the HUD's inventory have changed, llResetScript();//so reset the script to force it to check to see if the animation is the same } } run_time_permissions(integer permissions) { if(permissions & PERMISSION_TRIGGER_ANIMATION){//animation perms granted if(llGetInventoryType(strAnim)==INVENTORY_ANIMATION){//check there is actually an animation to play llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION,0));//play it } } } }
  5. Or, since it's a HUD, so it's intended to be worn when used, this should be all you need state_entry() { if(llGetAttached()){ llRequestPermissions(llGetOwner(),PERMISSION_TRIGGER_ANIMATION); } } attach(key id) { if(id){ llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION); } } ETA: All my scripts for HUDs ask for permissions in state entry if worn, so I don't have to keep on attaching and detaching them during development and testing.
  6. Thanks. I've played with this but I'm finding that triggering the turn in a separate script works more reliably for what I'm trying to do here, so I think I'll stick with that. Thanks too, to my friend @Rolig Loon, who reminded me of Void Singer's uSteppedRotLookAt routine, which turns the NPC very smoothly.
  7. Could they not use pathfinding and llEvade?
  8. And most Brits gave up believing much Nick Clegg ever says after, in 2010, he took the Liberal Democrats into their ill-advised coalition government with David Cameron's Conservatives, with Clegg as "deputy Prime Minister" (a meaningless role most, if not all, the time, a bit like "senior VP for blue skies thinking"), which cost his party 49 seats in the 2015 election, leaving them with only 8 remaining MPs and paving the way for Brexit.
  9. I've tried sleeping the script but the only way I've found so far to get this to work is to call llDeleteCharacter in the main script and then send a link message to a helper script, which reads the target's position and turns to face them. It doesn't work (or not with any value for llSleep() I've tried) in the main script. I feel as if there's something obvious I must be missing -- it can't be an usual requirement, I'd have thought, that a pathfinding character turns to face in a particular direction, and having to delete the character, only to re-create it after asking a separate script to rotate the object, seems a bit clunky, so say the least. Isn't there a better way to do it?
  10. and I can't understand why. The animesh NPC calls llWanderWithin. While it's wandering, something happens to attract its attention, and I want it to stop and look at whatever that might be. This should do the trick, I would have thought, and it does stop it, start the stand animation and gives the expected debug message with the correct rotation, but it refuses to turn. faceTarget(key id){ kTarget = id; llExecCharacterCmd(CHARACTER_CMD_SMOOTH_STOP, []); lTemp = llGetObjectDetails(kTarget, [OBJECT_POS,OBJECT_ROT]); playObjectAnim(strStandAnim);//simple userfunction to start new anim and stop old one vTargetPos = llList2Vector(lTemp, 0); rTargetRot = llList2Rot(lTemp,1); vPos= llGetPos(); rRot = llGetRot(); rotation r = llRotBetween(<1,0,0>,llVecNorm(<vTargetPos.x - vPos.x,vTargetPos.y - vPos.y,0.0>)); debugSay("turning to face "+(string)r); //llSetRot(r); llRotLookAt(r, fStrength, fDamping); } Either llSetRot or llRotLookAt should turn it, I'd have thought, but neither do, and I've tried a whole range of values for strength and damping. What am I doing wrong, or is there something else I should try? Is there something clever I can do with llNavigateTo or llPursue or something?
  11. https://www.goodreads.com/en/book/show/55643287
  12. I would take it out of setAnimation completely, as indicated above. I was trying to think of where permissions errors could come from, and that seemed an obvious place where, under particular circumstances, the script could try to start an animation without holding the necessary permissions from the right avatar.
  13. I don't know if this is relevant but I'm a bit puzzled by setAnimation(integer num) { //llOwnerSay("Start Animation - " + (string)num); if(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) { llStopAnimation(current_animation); } current_animation = llList2String(list_animations,num); llRequestPermissions(claimed_key,PERMISSION_TRIGGER_ANIMATION); llStartAnimation(current_animation); } I would set the value of the variable current_animation and then request animations permissions, and then, in the run_time_permissions event, call llStartAnimation(current_animation) there, at a point when there's no question whether the script has animation perms or not. I guess you could also make assurance doubly sure by checking who llGetPermissionsKey is, but I really would try moving llStartAnimation and see it that improves anything.
  14. So you don't mix up two instances of the same object, belonging to different owners, you may want to keep an eye on llGetOwnerKey(id) when tracking messages. Checking the parcel details for the parcel on which an object is located will often tell you what you need to know, too. You might also want to look at the various land ownership functions.
  15. I would recommend always explicitly stopping the sit animation when someone first sits on anything, in the run_time_permissions event at the same time you start the first animation. It's one of those things that you can often get away with not bothering about but sooner or later you regret it, and then it's sometimes very puzzling. ETA: While I think of it, it's also good practice not only explicitly to stop the existing animation when the avatar stands but also to start the default stand animation. That's because llStopAnimation sends a message to your viewer to stop playing the animation, but if it's a looping animation, it'll continue until the end of the loop unless over-written by another animation. If you're wearing an AO, then that'll take over, but people whose AOs are turned off can find themselves stuck in the sit animation until they start to walk unless you explicitly tell the viewer to play a stand animation when they cease to be seated (I don't say "stand up" because they won't unless told to!)..
  16. You can identify particular object meshes (rather than instances of them) with llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0). So something like this might be helpful string strMcGuffinCreationTime; integer iMcGuffinChannel; default { state_entry() { } listen(integer channel, string name, key id, string message){ string strTimestamp = llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0); if(llList2String(llGetObjectDetails(id,[OBJECT_CREATION_TIME]),0)==strMcGuffinCreationTime){ //then the message is from a McGuffin of some sort if(llGetOwnerKey(id) == llGetOwner()){ //then it's from a McGuffin belonging to my owner. } } } } Also, since any object you're wearing (or sitting on), and only those objects, will receive messages sent via llRegionSayTo, you can be pretty sure that llRegionSayTo(id, McGuffinChannel, message) will reach only the McGuffin that id is wearing, and no one else's.
  17. Try default { state_entry() { llSetPrimMediaParams(3,[ PRIM_MEDIA_AUTO_PLAY,TRUE, PRIM_MEDIA_PERMS_CONTROL,PRIM_MEDIA_PERM_NONE,//hides control bar completely //PRIM_MEDIA_CONTROLS,1, PRIM_MEDIA_CURRENT_URL,"http://google.com", PRIM_MEDIA_HOME_URL,"http://google.com", PRIM_MEDIA_HEIGHT_PIXELS,512, PRIM_MEDIA_WIDTH_PIXELS,512]); } }
  18. As a scripter, I've come to realise that, when I work directly with animators, it's often so helpful to be able to ask them how many frames each animation contains, and its frame rate, so I know exactly how long it lasts and can thus more readily synchronise things. I don't buy animations myself, but my impression is that people who sell animations don't routinely include this kind of information, and it occurs to me that at least some people would use it if it were available. It would certainly make it easier to explore AvSitter's and nPose's "scenes" features, which I think could be more widely used, and I certainly find it invaluable when working with animesh. Certainly in the Scripting forum people regularly ask they can know when an animation ends, and at the moment, the answer may well involve the stopwatch feature on your phone, which isn't really optimal. Is there a reason not to provide this data? Probably few people would use it, but those who do would be very grateful for it, I suspect.
  19. I don't think you can actually delete a HUD while you're wearing it, can you? Permission to animate an avatar is granted to a particular instance of a script, so if I have two copies of a HUD in my inventory, one which I'm wearing (HUD A) and one which I'm not (HUD B), and you grant HUD A permission to animate you, then I can remove HUD A and replace it and, if I've scripted it in a certain way, it will retain permission to animate you the next time I wear it. However, if I wear HUD B, although the script it contains is apparently identical to that in HUD A, it won't have the same animation permissions, so I can use it to animate you only if you've separately granted animation permissions to HUD B too. I may be missing something but I can't immediately see a way to copy or transfer animation permissions between different instances of the same script, so that I can obtain permission for one instance of the HUD to animate you, remove and delete it, and then use a separate copy of the HUD (as opposed to the one I've just deleted and then retrieved from Trash) to animate you without first obtaining animation permissions for that script too. These exploits work only if the two avatars are on the same region, so my advice to people against whom they are used is always to avoid the person griefing you, and the regions they hang out on, and to AR them for harassment every time they try to use their gadget. They'll soon get bored.
  20. I used OpenSUSE years ago for a while, and liked it, but eventually it was too much hassle keeping track of what was compatible and what wasn't, and what worked well and what didn't, that I gave up. If Linux can't now be used to run either the Official viewer or Catznip, it's not going to be much use to me, I think, though obviously my SL isn't much like most people's.
  21. First question: how well do the Official Viewer, Firestorm, Marine's RLV viewer and Catznip work in Linux (including stuff like sound and shared media)? I often need all four to test scripts.
  22. I was underwhelmed by the names too, but then I thought that, since there are no circumstances in which I can imagine spending US$39.99 to change my (or any of my alts') last names to anything, this must mean I'm probably not the target market LL can have in mind when they devise them.
  23. As it is in the UK, and many other places too.
  24. Yes, and I think that's the problem. I mean, I regard the foetal heartbeat test as not terribly useful, since if a heart transplant donor isn't dead before their still-beating and perfectly healthy heart is removed for transplant, they certainly are afterwards, which must mean a murder has been committed at some point. For myself, I'd rather use similar criteria to determine when life begins to those we use to determine when it ends (and patients are certified as being dead and their vital organs therefore available for transplant, if that was what they wanted), and ask when the organised electrical activity in the foetus' developing brain becomes recognisably that of a living human being, as it begins to regulate its own automatic bodily processes and chemistry (that's some time in the seventh month, I believe). I'm not saying that's the best test, but at least I can justify my reasoning with reference to something other than theology and the question of at what point the body becomes ensouled. That's why I'm so uncomfortable arguing about abortion -- so often, it comes down to an argument about religion, and I don't think that courts, legislatures or this forum are particularly good places to conduct such debates.
  25. I'm sorry, but I don't quite see why the fact a particular woman might later come to regret her decision to have an abortion is any sort of argument for restricting that right. After all, plenty of people certainly also come to regret having children for whatever reason, and certainly plenty of people later come to regret all sorts of decisions, whether it's getting married, joining the army, voting for a particular political candidate or buying a particular house or other major purchase. The fact someone may later come to regret a particular decision is no reason for their government to try to stop her taking it.
×
×
  • Create New...