Jump to content

testgenord1

Resident
  • Content Count

    109
  • Joined

  • Last visited

Community Reputation

17 Good

About testgenord1

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Update: I've found the solution myself now. I forgot that the position from which the pieces are scattered out is not the start position of the particular piece, but the center of the puzzle "gamepos". So the updated version looks as follows now: float circle_radius = 5.0; float circle_height = -0.5; float position_angle = llFrand(TWO_PI); vector piece_position = gamepos + <circle_radius,0,circle_height> * llEuler2Rot(<0,0,position_angle>); float rotation_angle = llFrand(TWO_PI); rotation piece_rotation = llEule
  2. Thank you very much for your help! It's improved the situation significantly. To give one clarification first of all, the puzzle pieces are not linked to the puzzle root prim. Each piece is an unlinked prim and has the particular script in its inventory. This even simplifies the situation a bit, I think. However, it seems to make it harder to arrange the pieces in such a beautiful perfect circular shape, as in your screenshot. In my version, the pieces now really scatter randomly within the radius. This not a big problem since it already fulfills the requirements of the ran
  3. Thank you very much for your suggestions. I've tested both and they both work. The method using llRot2Fwd worked better than my original one, but still caused the division into to opposite piles. The other method, using a list containing the prim positions works more exactly. For whatever reason, it keeps placing some puzzle pieces in the exact same position as another piece, although none of the positions on the list are equal. Can you maybe see why this is the case? Thank you very much for your help anyway! ๐Ÿ™‚ list lpos=[ <0.0,5.0,0.1>,<1.0,5.0,0.1>,<2.0,5
  4. Hi! I've got a script of a jiggsaw puzzle. Before the puzzle can be played, the pieces are spread around from their initial position, which is the complete puzzle image. - They are supposed to be spread in a random fashion, so that the pieces are being mixed. - They are also supposed to be spread within a certain radius, so that all pieces always remain in the sight of the person playing. - The puzzle is then supposed to be assembled in the initial position again, which is in the center of the circle. The script I've come up with so far arranges the pieces in two loose piles
  5. Thank you, Mollymews! I'd made the same experience before, but couldn't make any sense of it. This explains it now, I guess. Thank you very much for taking your time and giving this helpful tip!๐Ÿ™‚๐Ÿ‘
  6. Hi again, and a Happy New Year to everyone, first of all!๐Ÿ˜Ž๐Ÿพ๐Ÿฅ‚ After experimenting a bit more, I've made an observation that I can't really make any sense of: The problem with the timer described above went away when I arranged the timer and listener event in the same order as the llSetTimer and llListen commands before (s. script excerpt below). I can't quite understand why the order of the events in the script should make any difference. Do you maybe have an idea? Thank you! ... default { touch_start (integer num) { llSetTimerEvent(1.0); //first: llSetTi
  7. Thank you very much for your quick and detailed reply!โ˜บ๏ธ I wouldn't have come up with these ideas on my own. This explains everything to me at this point. Again, thank you very much.๐Ÿ‘๐Ÿ™‚
  8. Hi! I've got a script that is supposed to play a random sound out of 4 sound files in the inventory of the prim. This means that whenever the script is started, any of the 4 sounds is supposed to be played by a random choice. I've used llFrand to create a "random" choice for this. Here is the part of the script: isound = (integer)llFrand(4.0); llPlaySound(llGetInventoryName(INVENTORY_SOUND,isound),1.0); There are three things I couldn't quite figure out. 1. The float in llFrand is in the range between 0 and the maximum number (given in the brackets). Is the first sound in
  9. //https://community.secondlife.com/forums/topic/444235-quiz-using-dialog-menu/ integer gListen; integer time = 180; integer ttime; integer seconds; integer points; key player; string nameplayer; integer gameover; integer CHANNEL = -886; integer index; string answer; integer channelgerman = -1291; string quizname; integer iAnswered; list lSounds = [ "6e517cde-066f-455e-8c6b-f1c33be90dea", "611c9470-507e-4471-8ce2-5ed0962e4c85", "b1e78aa1-52b7-482f-a48a-57e3ddff81fc", "7b978d05-b3bd-4e6f-892f-92dc4845ddd8", "64319812-dab1-4e89-b1ca-5fc937b8d94a", "720ff3dd-8fc6-4523-9670-139df57527f3"]; list q
  10. Thank you very much for your ideas. Theyโ€˜re awesome.๐Ÿ˜Š Iโ€˜ll try them out in the next days when I have some time. @Qie Niangao: Hm, I suspected that, too. But the original script is exactly the way I posted it here. Maybe my region is contributing to the problem. Sometimes scripts donโ€˜t fully function there that work in other regions (OpenSim). Iโ€˜ll try out Roligโ€˜s suggestion using llOwnerSay, which I havenโ€˜t done, yet. Maybe Iโ€˜ll find out more this way. Iโ€˜ll come back and let you know then. Thank you very much for your help, again!
  11. Thank you very much for your advice. This all sounds really interesting. ๐Ÿ™‚ The llSleep actually is what I was trying to replace by using the timer. The script had quite a long processing time span in the "top scripts" list when using llSleep. Replacing llSleep seems to have reduced that processing time quite a bit. I've read that llSleep blocks one entire thread of the SIM engine for as long as it is active. Since I would like to use many of these quiz scripts in my region, I figured, to prevent lag, it might make sense to get rid of as many llSleep commands as possible. I'm
  12. Hi! I've got a script of a multiple choice quiz. The quiz asks the player questions using a dialog. The player only has a certain time to finish the quiz, otherwise the script is reset. The script works so far. Now the problem: The timer does not work. (It works in the first round, but, strangely, not the following rounds afterwards.) I assume the timer event is replaced by the listen event, and hence, it stops working. Is that the cause of the problem? (But then again, why does it work in the first round? Plus, when I cut the script significantly shorter, the timer is
  13. Wow, so many replies in such a short time. This helps me a lot, thank you very much. I'm still struggling to understand some of the details, but I'll just try to remember.๐Ÿ˜‰ Thank you very much for your help, once again!
  14. Hi! I've written a script that starts on touch_start. After starting the script, the touch_start event is supposed to be deactivated for some time, so that nobody can restart the script as long as the process has not been finished: integer on; touch_start (integer num) { if(!on) { on = TRUE; *do something* } else { return; } This seems to work (the only thing I'm not quite sure about is the "else" part with "return". Couldn't you just leave the "else" part out?) Now my main question: I
  15. Thanks a million, Mollymews! This script works really beautifully. I couldn't have done it without your help. I'm posting the updated quiz below. Maybe someone has some use for it later. I've probably still left some flaws in the script, so everybody still feel free to comment further. Again, thank you so much for your help!๐Ÿ™‚ list lpoints; list lnames; integer length; integer ListenHandle; integer inumber = 1; //number of expected correct answers string sname; default { state_entry() { ListenHandle = llListen(-1121,"",NULL_KEY,""); } listen(integer channe
×
×
  • Create New...