Jump to content

Frankie Rockett

Resident
  • Content Count

    35
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Frankie Rockett

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Two excellent approaches worth looking into. With Animats approach I could presumably have the script check it's ownership, then delete itself if it's not myself. I'll have to test that out and see what I think. Nova's idea thrills me - it sounds like magic! How do I access this 'central controller prim'? Do you mean the root prim? Assuming so, how on earth do I get it to rebuild the state of itself when it was a multi-prim object? Once I know that (which I'd love to at this point anyway), the base question still applies: how do I give the controller/or/root prim, complete with it's parameters and script for rebuilding, to the user? Frankie.
  2. Hi Gang I want to know if I can programatically get an object to offer itself, without having a copy of itself inside, so 'llGiveInventory' is not an option. I have what might seem like a perverse requirement here so a few words of explanation before I get back to the question. I have what for shorthand I'll call a 'game' for solo players in which objects are rezzed around a central controlling prim (that I'll refer to as the CP). The CP listens for the UUID of the latest prim to be rezzed and immediately links to it. This leads to a large object building up by accretion as more objects are added. At the end of the game the user clicks a 'Clear' object that tells the CP that a Clear is requested. The CP sheds everything by a) declaring itself to be Temporary, b) unlinking all the child prims, and c) declaring itself to be not temporary. So 60 seconds later, the setup is clear and ready for the next game. Now, in testing, users have expressed the wish to have a copy of the object (prior to clearing it). The object contains a listen remember, so in theory I could send a 'Give' command to it for it offer a clone of itself to the player. Or could I? To the best of my rather incomplete knowledge, llGiveInventory is the only function that might do this, but since the object was dynamically created, there can be no copy of itself within itself that it could offer to give via llGiveInventory. So; is there a way to programatically have a script offer the object - rather than an item in it's inventory? I can't decide if there's a glaringly obvious way to do this, or it's actually impossible. Nothing in between those two extremes I bet. Thoughts please? Frankie
  3. Epilogue. The solution worked flawlessly. Fenix's proof of concept script does the job really well. The only tweak I had to make was as a result of idiot-proof testing. I found that if I clicked like mad creating scores of prims per second then hit 'clear' while things were still rezzing and linking, then - after a looong delay for things to catch up, two or three child prims were left over - still attached, and not temporary. So I wrote a little delay loop (because llSleep makes everything go brain dead so nothing gets done) before and after the unlinking call and that seemed to make it bullet proof / vandal proof. Success! Thanks to everyone again - you know who you are - for your superb insights! Cheers.
  4. Wow Lucia! Yes, danger of information overload, yet I understood 87.396% of it. More than enough to see what an important set of considerations I'd never have dreamed off were it not for your input. I can imagine myself scratching my head for days and wasting hour upon hour trying to figure out why no more object returns were happening. And I've barely touched on half your contribution here, but it's all noted (and in need of sixteen re-readings to be sure I got the rest). Thank you so much. Qie - again, thank you for your input. Yes, I am leaning towards Fenix's approach like the Tower of Piza is leaning towards agreeing with gravity. Not only to circumvent the issues Lucia points to but also the general messiness of having my Inv fill up with what is conceptually at least, other people's junk. I still need to do a ton of experiments around circumventing the PERMISSION_CHANGE_LINKS complication, but it feels like the avenue I should explore ahead of the llReturnObjectsByID approach. Nice to have a plan B though, so thanks again Rolig. Oh, and a plan C too if you're on the right lines saying that a targeted listen is no biggie, together with a built in limit to how many prims I'll permit to be rezzed in one go. I kind of think 200 would be the limit though for game-specific reasons. I'll keep this thread posted with findings as I go along. Cheers.
  5. Thank you Everyone! To Profaitchikenz: Thank you so much! That is brilliant. I am indebted to you. After a few hccups I realised I had been 'randomising' the wrong parameter. I needed to leave 90 in the second parameter slot and randomise the first, the x parameter. Then it all worked perfectly. Thank you. A huge Thank you too to Wulfie for fearlessly slashing away the complexity of rotations for me! Education by subtraction has a lot to be said for it - so seriously, thank you Wulfie. Lastly, thank you to Mollymews for adding all the complexity back in with your background reading! Hahaha! I'm only teasing - thank you. Cheers to all!
  6. Hi Wulfie I tried my (clearly faulty) implementation of your very clear instructions, with the resukt that the rezzor itself started to randomly rotate, rather than the thing rezzed. Here's the code. My best guess was to try to change the definition of rezRot by assigning rotation rezRot = llSetRot(llEuler2Rot(object_rot * DEG_TO_RAD)); but that's a syntax error! can you see where I'm going wrong? Oh - the lines of yours I took and modified for this script's variable names is enclosed in the section marked 'Edit's'. Profaitchikenz - thank you for your suggestion too, which I had to try because it seemed so deliciously simple. No joy. So I found that changing: rotation relativeRot = <0.707107, 0.707107, 0.707107, 0.707107>; to rotation relativeRot = <0.0 0.707107, 0.0, 0.707107>; yields functionally identical results in that it rezes the 'picture prim' in the correct initial orientation (face X 'forwards') so I naturally assumed that changing the 2nd parameter would change the 'spin' of the image as required. No dice. Keeping within the 0 - 1.0 range as you said, I tried for example <0.0, 0.1, 0.0, 0.707107>; which made it rotate on the wrong axis. Remembering your comment about making the 4th parameter the same. I went with <0.0, 0.1, 0.0 , 0.1>; - all good. Except when I tried other values like <0.0, 0.4, 0.0 , 0.4>; and <0.0, 0.9, 0.0 , 0.9>; - no rotation occured at all. The various changes of value had no effect on rotation of the rezzed item. 'Clearly shome mishtake', as folk start saying nearer Christmas. Do you have a hair of the dog for me?! Thank you all.
  7. Hi Try as I might I have to admit that I will never understand the maths or the geometry behind anything other than 'degrees' of rotation along three axis in SL. I say this upfront in case anyone tries to explain underlaying concepts to me! Keep it simple (because I'm) stupid (when it comes to this stuff). I have a script rezzing a flattened square prim with an image on it's front-most face that rez's against a wall I have provided. I have it working so it functions no matter which compass point the wall faces. However what I'd like to do is have it's orientation on one axis randomly oriented when it rezs. Imageine a poster that might be upside down, sideways, or any other of the 360 available angles. So the bones of what I'm working with is here: It's the object's own Z axis I need to spin. Everything I try seems to cause complex interactions and rotate the prim on more than one axis. Take the first line for example. If I change any of the 4 parameters, the object will rez skewed on at least two axis. I have spent hour (and hours...) on this and would be so grateful to know at what point I can inject values between 1 & 360 to have the object still flat against the wall but rotated some - like clock hands for example. Thank you!
  8. Hi all So much for me to digest! I used to code daily but 'use it or loose it' applies here, and as I haven't got down and dirty for literally years, absorbing some of your fine ideas is a little overwhelming. Fenix and Rolig have (with a great supporting cast), between them I think, given me a workable alternative to a 'choir of listens'! Please let me play around with your combined suggestions over the next week or so to see where they lead. Thank you again so much for donating your brilliances! Much appreciated!! Frankie.
  9. Hi Rolig + Hi Mollymews! Thank you for those remarks. I think I want to try Rolig's idea, especially as Mollymews points out, it involves least modification to what I have now. Although I do need to speak to the land owner. Can I take it then Rolig that he or she could create a parcel for me, and not fear that my PERMISSION_RETURN_OBJECTS could affect anything he owns outside 'my' parcel? And just for completeness, how (in what menu/dialogue) would he grant me such a permission? Cheers.
  10. Hi Rolig! Thank you for your idea. The game won't always be on my land, which as you understand would scuttle that approach. If it was on my land, wouldn't the memory requirements be beyond an lsl script? Saving a little 'array' of - let's say worst case - 250 UUID's? Cheers
  11. Hi Fenix, and Hi Profaitchikenz too. (I greeted you a second later Profaitchikenz, just to keep it straight!) Thank you both for your suggestions. Fenix, one question. You say the rezing prim (my prim A) would " automatically know" the UUID of the prims it's rezzing. How? Or more exactly, how would I access that value please? I love your suggestion overall, except for the ugly caveat concerning PERMISSION_CHANGE_LINKS. So I have an idea/question about how to get around that. Supposing my 'prim B' were a permanent, invisible part of the game, and once the game is ready for others, I give it the permission once that it wants. Then later, with lots of child prims attached, and hearing my 'Clear' command, could it contain a script that effectively says 'delete all child prims'? - excepting itself. Then, on future runs of the game, could it be told to link to a new series of prims as they are rezzed, by their UUID's, without needing PERMISSION_CHANGE_LINKS again? Or is that permission required on a prim by prim basis? Thank you for your idea Profaitchikenz but I see problems with it, like waiting an age for some potential maximum number of prims to rez and link, even if the subsequent player only used a fraction of what was invisibly prepared. Cheers!
  12. Hi! I have an application working at the moment that I'd like to rewrite in a much more friendly way and I wonder if you guys and girls can help? I have a game that rezs many prims. It's up to the player but there might be a hundred or more. The region's the limit, theoretically. When the game is over, all the prims (which are all very close by and very close together) need deleting. Currently they all have a 'listen' in them, listening on a particular channel for the 'Clear' command, whereupon they 'die'. I would love to not be creating scores or even hundreds of listens! So I am wondering how else to do it? I was musing that perhaps there is a way to link two or more prims that are and remain separate from the prim that created them? Is that do-able? So to be clear, prim A contains the script and the means of spawning prim B, C, D and so on. Prim A creates B initially, but B is unique as the first one spawned, it's set to contain the only 'listen' needed. As each new prim is spawned, it links to prim B (or any of the others except A). When the game is over, a 'clear' command causes prim B to delete, taking everything attached to it with it. Ok, that's my uninformed guess! Might that work? What are the key functions that I might need to get it going? And of course, are there any other exotic techniques I might employ to achieve the same functionality? Thank you for your thoughts!
  13. Yes, that's what I thought Qie was describing. Hence my illustration to counter the theory - how the texture seems not to have any transparent portions in this case.
  14. Not quite clear if that's a question - as it starts out, or who the subject is - in what seems like a statement in the middle section, before reaching what looks to me like an exclamation. But - 'yeah right!'
  15. Oh that would be good! I should set aside my conviction that all I'd see is a 'transparent' texture and try it. There are two barriers to this of course. For one it's broken and I'm not sure I learnt much from breaking it; buying another - ditto. Secondly, the 'flashing' on and off of tail positions is too fast for me to select it anew and inspect the texture - it would have cycled well past that tail's (in)visibility by then I would imagine.
×
×
  • Create New...