Jump to content

LepreKhaun

Resident
  • Content Count

    1,384
  • Joined

  • Last visited

Community Reputation

152 Excellent

About LepreKhaun

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Qwalyphi Korpov wrote: ... I see that further responses will be of no use. The OP apparently has some agenda they are attempting to further here or some point they are trying to make that precludes any appeal to reason or fact. It's also obvious at this point that they thrive on argument, dissension and the attention they get by flaunting the rules. The only way I see to deal with that is to do no more than point out their misbehavior so others don't get the idea that it's appropriate in our forums and, if they persist, report it to the moderators. That would at least lower the incidence of disruptive noise until this problem is resolved. For those that do wish to be recognized as creditable programmers, modifying or incorporating other people's work into your own efforts is allowable, but only as long as you follow the licensing that applies to your source. It's not difficult to do and shows others that you take enough pride in your creation to show due respect to the original author(s) whose work you are building upon.
  2. Miranda Umino wrote: Yes , but Wandering SoulStar wants to use llRemoteloadScriptPin So the state_entry will be the first event triggered . And llGetStartparemeter will know wich parameter we have sent to llRemoteloadScriptPin You're missing the point- state_entry() is an event handler that may be used in any state. Only the state_entry() specifically within the default{} state is triggered on reset. This does not apply to any other state's state_entry(). Dora was making a necessary clarification of this so beginners reading the convo become aware of the difference and not wonder later why their state_entry() in (say) state working{} isn't being triggered on reset. Because it won't, that .state_entry() will wait to be triggered until the working state is later entered.
  3. I'm delighted that you are following my suggestion to properly comment your code, but if you wish to be taken seriously as a programmer you should correctly use licenses when including or modifying the work of other people. Disregarding the terms of both the CC-BY-3.0 (which covers anything published under that license) and the CC-BY-SA (which covers anything extracted from the LSL Portal wiki) might lead beginners to believe that these can be ignored with impunity, which is definitely not the case. Full, correct attribution and following licensing requirements is a sign of professionalism. Here's a link to a introduction to these licenses and how to correctly use them. Please take the time to study it and have enough respect for your fellow content creators and other beginners to follow them properly.
  4. Well, one does need to take a break from building at times, even if it is to make another pot of coffee. :smileylol:
  5. It's difficult to guess exactly what you need without looking at a complete specification of the problem. However, I'll venture a possible solution if it's a matter of just distributing and activating one script among a number of rezzed prims: Have the script in the inventory prim to begin with, but have only a listen() event handler in the default state and, when triggered, have it switch to the "working" state. You could also toggle between the default and working states the same way, effectively turning "on" and "off" the script. ETA: There are two ways to toggle back to default()- state default; and llResetScript();. They both will clear the event queue but the second also reinitializes your global variables and clears the timer.
  6. Perrie Juran wrote: LepreKhaun wrote: I've learned to be careful just rubbing a strange cat. Some of them don't like it and I've got some scars for not picking up on it in time. My neighbors dog and my cat got into it one day. My neighbor grabbed his dog. I grabbed my cat. This is when you learn how fast a cat really is. I never saw the swipe that layed open my arm. Faster than the blink of an eye. I've still got the scars too. (After that fight they never fought again. We actually found them sleeping together a couple of times) Delightful story, thanks for sharing! However, this is veering far from both the topic and the purpose of this forum which is for discussions about scripts and scripting. Perhaps we could talk about our pets in General Discussion some time.
  7. I feel a lot of difficulty in understanding the LSL event model is due to a pervasive looseness of the term "event" being used in place of a number of phrases that contain the word "event". Unfortunately, this looseness dates all the way back to the initial LSL language definitions and probably isn't changeable at this late date. I try to distinguish the differences in my own writing by, for instance, referring to the touch_end() "event handler" rather than the touch_end() "event" unless I'm actually talking about the message itself. Otherwise, the reader requires a certain level of understanding to correctly read what is being written in the context they find "event".
  8. Wandering Soulstar wrote: Thanks for the reply Nova ... In followup to this, and based on the actual situation of what I am trying to do. What I'll actually be doing is loading the script mentioned into another prim, using llRemoteLoadScriptPin, and having delt a bit deeper into what the wiki says about this function it indicates: 'When the script is set to run (with running, the running checkbox or llSetScriptState) state_entry will be queued.' Does this mean what I think, i.e. that the script will go through it's normal startup in the Default state? Even if when it was stopped it was in another state? Correct, the default State is always activated from scratch when a script is reset by any means and its state_entry() Event Handler will always take precedence in the Event Queue,
  9. Wandering Soulstar wrote: Hi All, Question regarding a script detecting owner change. Now I understand clearly from the Wiki that I can use the changed event with the CHANGED_OWNER flag to check this, but I have a specific scenario in mind: I own the script and the prim it is in. I Set the script to not running I then give the prim and script to another They then start the script running ?? Will the changed event then fire ?? Thanks in advance! Wanda Events, in their truest sense, are messages. The code in our LSL scripts have Event Handlers contained within States. When a State becomes active in a script, the script's Event Queue is cleared and the Event Handlers of the active State are registered with the server. Only registered Event Handlers can have an Event placed into a script's Event Queue. A script that is not running has no State active, no Event Handlers registered and, for that matter, no Event Queue to receive Events. This differs from a running script whose object is taken into inventory.; it's changed() Event Handler (if it's within an active State) remains registered and it also has an Event Queue which awaits processing until it is rezzed.
  10. See this thread for solution.
  11. I've learned to be careful just rubbing a strange cat. Some of them don't like it and I've got some scars for not picking up on it in time.
  12. Here's a good link on how to do the Blender materials to SL faces bit.
  13. In Blender, make separate materials (up to eight) that will become faces within SL. Each face can be UV mapped and textured on its own that way.
  14. Join everything in Blender so it's one object. Make a model for the lowest and (possibly) next lowest LOD that is nothing but elongated cubes. No need for that much detail at further distances. Use the physics model as you have it, it'll work correctly for a single object. Otherwise you'll need a physics model for each separate mesh. This should reduce your Server weight from 3.50 to 0.50 (each mesh object requires 0.50) and both Physics weight (which is currently driving your LI) and Download weight (which is being driven by the lowest LODs) to less than 1.0.
  15. Very well done and illustrative how LSL (with all its warts LOL) can be used to implement even advanced math algorithms. With its reproducible pseudorandom results within a set, I can see how this would be useful for a number of game situations and your excellent commenting should enable any intermediate coder the means to modify it to their use.
×
×
  • Create New...