Help with turning scripts on and off please

[Cheewha Palen]

Hello all.

I am not sure how to do this, I need a separate script, something I can drop in  an item with other scripts which would listen for a regionsay and then activate the other script(s) in the item inventory.

Its a sort of by pass for permissions. I want an object to send you on a quest to get something before that object will work. (like a key to a door).

Instead of mucking about with inventory items and uuid's and fuss, I am going to have the item that gives you the quest ( a collision plate on the ground) shout to the quest container to "activate". (A box with a key inside) It tells you "inventory item given" (not really) and it shouts to the next item to activate ( the door). So pressure plate activates box with key inside which activates the door. The door was "locked" (scripts sleeping) until you did the steps mentioned.

 

So I need to figure out how to structure a script to activate sleeping scripts, and also a generic listening format to throw into other codes.

 

I think timer and sleep will do this with listen but I cannot figure out square one (yes I know "default()" but you know what I am saying).

 

Can anyone please offer advice?

Cheewha Palen

 

 

[Rolig Loon]

I don't see why you need to be turning an inactive script on.  What you have described is simply a door that opens when you step on a collision plate.  Just use your favorite door script and make it activated only by collision with that collision prim.  If you want to heighten the suspense, put in a short time delay and maybe the sounds of a complicated lock system whirring away, accompanied by arcane messages about the imaginary key.  It can all be done by that door script alone.

[Cheewha Palen]

Sorry maybe I wasnt clear Rollig, and thank you for the response. The reason. is a series of perms between objects. if the collision plate was the object i wanted to activate the door that would not be an issue.

I am creating a narrative walk through that also gives tasks or quests. For example with the door. The door needs a key found before you can open it so you must easter egg hunt to find the object needed. The door needs a key before it will open. It is part of a narrative and not part of normal SL activity where a collision plate and door would be obvious.

But I have been away for a while and my scripting is rusty at best.

so here is the idea I am working with. The following would occur to get a elevator lift working....

Box 1: narrative prim, generator room
Box 2: Explorer trunk, crash site
Box 3: Generator mechinism, generator room
Box 4: Rooftop fan, generator room
Box 5: Lighthouse Lift, light house

////////////////////////////////////////////////

Box1 on collision says narrative statement. shouts to Box2 script activation.

Box2 on Touch says narrative statement. shouts to Box3 script activation.

Box3 on Touch menu choice "repair" sits avatar into "working on it" animation. plays machinery sounds. De-alpha's the hidden zappacitor so it is now visible. Shouts script activation to both boxes 4 and 5.

Box4 begins spinning per target omega script to depict the generator is now functioning.

Box5 is now operational. Lift may now be used.

/////this method of shouts eliminates the fuss for inventory items and uuid identification.

///////////////

I hope this helps. your time is apreciated.

Cheewha

 

[DoteDote Edison]

From what you describe, I'd recommend doing a bit more work to establish a datebase. That can be short-term SL-based in which you have a server object that registers the progress of a finite number of avatars (limited by script memory), or an offline DB that keeps track of the progress of nearly infinite avatars. In essense, an avatar activates tep one, gets logged in the DB, and is allowed to progress to the next step.

Now, if you're intent on doing it all within SL, without tracking UUIDs, and without the DB hassles, you'll have limits. For instance, if two people are progressing at the same time, one would be able to skip ahead due to the progress of the other (a door would be opened by one avatar, allowing a second to sneak through). However, here's how you can do what you want - no need for stopping scripts which is rarely a good idea!

Simply set a flag integer in each script to enable its action TRUE/FALSE. For instance:

User interacts with Box 1 and it shouts, "ENABLE BOX 2".

Box 2 hears the message and sets its ENABLE variable to TRUE. When the user interacts with Box 2, it tests: if ENABLE==TRUE {openTrunk; shout "ENABLE BOX 3"}

Box 3 hears Box 2 and enables itself for the next step.

Each box could set a timer that after, say 5 minutes, the ENABLE flag gets reset to FALSE. That may work for what you want.

[LepreKhaun]

Instead of having the separate objects trying to keep track of what an avatar has done, you might find it much simpler having an attachment that is required to be worn to make progress. This not only keeps your game logic in one place in case you decide to change things (and you will!) but makes it much easier if you have a group going through since each individual's progress is readily available as needed.

 

Explore a bit within the tunnel at http://maps.secondlife.com/secondlife/Pyri%20Peaks/130/109/115 to see how this is done.

[Cheewha Palen]

Thank you for the response. This is an interactive narrative walk through I plan on releasing as .oar files to the open source community when finished. Just a project I am workig on that would be something like an adventure book( make this choice page 92 or this one page 33) with tasks similar to oblivion style quests to advance the story. Each oar is a "moment" in the story so each narrative is short. Basically you enter a situation have a task or few to do and then the objective is complete.

So it is something that an individual would walk through or play and any other NPCs would be Bots which is why i wasnt keeping progress monitored. Once all the steps are done the challenge is completed and you are finished with that scene.

It is pretty simple really and I hope it to be an immersive environment something like Myst or Riven. Its more story driven than action.

The enable function you describe sounds like it would keep a script at bay until called by the last gatekeeper in the chain of each event. Could you give or refer an example of this in use?

Again thank you and others for their attention and time. I appreciate you!

Cheewha Palen

 

 Edit: Sorry if I am a bit dolty on scripts these days, I am coming back after almost two years away from the metaverse. There was a time when I was almost dangerous and savvy with all this, and thankfully I still have copies of any scripts I accomplished then. I had never tried to do a chain of events so this is knew to me on top of the rustiness.

 

Thank you again.

[Cheewha Palen]

---

Rolig Loon wrote:

I don't see why you need to be turning an inactive script on.

 

Because I do not want the script to do its part until its told it can. As a Senior helper could you offer any advice on this idea please? You critiqued my idea without really contributing any advice or solution.There are calls like  llSetScriptState("Name_of_script", TRUE/FALSE); that i found in the archives last night that seems to be the type of funtion i am looking for. (found two setscriptstate and reset other script). But I dont understand them enough to make this work.

Help is needed. Advise is appreciated.

Thank you

cheewha

 

[Rolig Loon]

I see what you are trying to do now, but I agree with both DoteDote and LepreLKhaun that there are much simpler (and more reliable) ways to get there than by turning scripts off and on.  One of the challenges of scripting is to step back from a task and see it first as a design problem rather than looking too quickly for a technical solution.  You began your thread here by saying "I need a separate script, something I can drop in  an item with other scripts which would listen for a regionsay and then activate the other script(s) in the item inventory."  What the three of us have each said is that the place to start is before that.

DoteDote and LepreKhaun have each offered suggestions that accept your self-imposed limiting condition -- the sort of stuff that you called "mucking about with inventory items and uuid's and fuss".  Their suggestions would both work, and would be simpler than turning scripts off and on, IMO.  I see another route. You are faced with a question in cryptology (not my field, but I appreciate the basic outlines).  You have a series of tasks for the user to perform, and you need to have some way to verify that the user is authorized to do them, and in the correct order.  You even phrase the problem in terms of needing a key. 

If I were doing this job, I might write the access script at each station in your quest to listen for a chat command on a private channel, and would think of ways to pass that channel number to the user as s/he completes an authorizing task beforehand.  Or, instead of a private channel, I might pass the user a key that is hashed with the user's UUID and therefore personalized.  The script at the next access point, upon reversing the hash, would then only respond if that particular user offered the key in open chat.

I don't know which solution is the best one. I'm just suggesting that you might take a step back and consider design alternatives rather than locking yourself into one particular solution too early.

[steph Arnott]

Seems to me, that just going from one state to the next when that state has all the required parts. I.e.

state find walking stick,

store room entered and stick found,

move to next state.

State find book, etc

[Cheewha Palen]

"If I were doing this job, I might write the access script at each station in your quest to listen for a chat command on a private channel, and would think of ways to pass that channel number to the user as s/he completes an authorizing task beforehand.  Or, instead of a private channel, I might pass the user a key that is hashed with the user's UUID and therefore personalized.  The script at the next access point, upon reversing the hash, would then only respond if that particular user offered the key in open chat."

Thank you for this.
 The goal is mostly a narrative so chats pop up in the chat lines from collision boxes. "This flower smells nice" or "if I only had a key for this old chest" kinda stuff. I am trying to keep the person experiencing the narrative to stay out of their inventory and other SL norms which to me bumped the idea of inventory and uuid's (its not mucking...I just didn't know much about that stuff).

I like that you said "looking at it as design problem" because I am (as primmer not a scripter) so my request for a seperate script was based on modular thinking and that I could then adapt it for other uses. I never think, " i am going to write code for this" instead I look at a script and think " thats clever, what can I build based on this". in other words instead of just asking for a door that needs a key script, and one thats seperate, I was seeing this as options like a door and key, a generator and a part, an NPC and an item etc..thus giving lead way when designing.

The other suggestions offered by others were smart and well taken.

Hope that helps understand whats in my head for this project. Late nights and old age make me wonder if what I think and what I type make sense to anyone else sometimes : )

Thank you all. I will mess around some more with this stuff and report back soon.

Cheewha