question: script function,changing tranluscent factor and pass-through at the same time on touch

[MishkaKatyusha]

well im finaly making some headway in constructing a house as it were.

i had this idea for a door that would look more like a force field

 

but for this application the door would need to go from solid to passthrough on touch

and while this isnt entirely needed,but would be appreciated,id also like to know if it's possible to have the translucent factor or glow amount change at the same time

 

the primary reason why im trying for a forcefield style door is,due to the odd shape of the house,a normal door would be virtually impossible

[steph Arnott]

you would have to make the prim phantom. The other stuff you can set and change  also on touch.

[MishkaKatyusha]

oh i know about making an object passthrough,i just wasnt sure of how to rig that to happen on touch,and then to changeback again on touch

[Rolig Loon]

You ougfht to be able to manage all of those changes at once with the appropriate parameters in llSetLinkPrimitiveParams .  Create a simple toggle in the touch_start event to flip the parameters from solid to phantom (and glow/non glow, etc.) and back again.

[steph Arnott]

OK, well Rollig way is best, but if you learning script you may be better to use two states, as in defalt state makes it solid, next state not. You read that on the wiki in regards to multi  states

default state

touch

set prim parameters to not phantom and other stuff

goto next state

end this state

--------------------------------------

next state

touch

set parameters phantom and other stuff

go back to default state.

ADDED later you can put it in one state by toggling true or false, but at the moment you can just get each state right.

like this example

default {    state_entry() {		// run this code when entering the default state		// displays red "OFF" as floating text above the prim		llSetText("OFF", <1,0,0>, 1.0);	}    touch_start(integer num_detected) {		// when touched, switch to state named 'on'		state on;	}} state on {	state_entry() {		// run this code when entering state 'on'		// displays green "ON" as floating text above the prim		llSetText("ON", <0,1,0>, 1.0);	}	touch_start(integer num_detected) {		// when touched, switch to the default state		state default;	}}

 

[MishkaKatyusha]

very nice,i can see how it switches from one state to the other,even where to input the information for the state switching

 

this will be very fun to tinker with

[Qie Niangao]

Script states are trickier than they appear to folks first learning to script. Relevant to this thread in particular, touch_start is an event that interacts unexpectedly with state changes. Notably, in this example, if the "on" state didn't contain any touch-related event handlers and instead got back to "default" from some other trigger, the next touch would not be seen by the touch_start handler in that state. That is, the object would need to be clicked twice to register a touch_start. So, as a general rule, I use touch_end instead of touch_start when scripting with states.

(I may encounter this more than most, though, because the main reason I ever use states instead of global flags is to move into a no-touch state and hide the "touch me paw" mouse cursor when it's not appropriate.)

[MishkaKatyusha]

my scripting expertise in lsl only goes about as far as gingerly reprogramming some algebraic coordinates for rotation and changing what animation was used by the script in a bed.

 

this is why i asked on here about this sort of on touch forcefield

the thing i had in mind was very similar to how the glowing door functions on some of the "wizard" themed linden homes

 

though onstenibly with some differences.my idea was,poke for passthrough,shutoff of glow,

then once your inside the structure that the door is blocking the entrance too,you could poke the general door location again to turn it into solid,glow on

the translucensy factor would be 100% in both cases due to wanting a sort of energy field like appearence (relying mainly on the glow function for appearence)

and above all the primary reason for this is that the structure im trying to make the door for has an extremely..how do i say this in english "non-newtonian" shape.basically very little in recognizeable geometry,so the entrance look abit like an onion if you cut a chunk out of it with a serrated knife,so no door nor door function that exists for other homes (except maybe spaceship hangar bays) would work by my estimation.

it would be easy for me to make the mesh for the door shape but the programming is something i only jsut recently got into

(interesintg luck i have,being experienced in most other aspects of developement except for programming)

[Innula Zenovka]

I would suggest that you make the door frame and the force-field two different objects (which you then link).

The reason for this is that you'll need to switch the force-field's PRIM_PHYSICS_SHAPE_TYPE property between PRIM_PHYSICS_SHAPE_CONVEX and PRIM_PHYSICS_SHAPE_NONE to toggle between solid and phantom.   You have to set this property for the whole child prim (mesh) -- it can't be set for particular faces of the prim or mesh.

For what it's worth, I don't think I'd bother using states for a simple script like this (simple in the sense that you're doing only one thing -- toggling between two sets of prim parameters for the door when you touch it -- I realise it probably doesn't feel simple to do!).  

Nothing wrong with using states but it seems to be complicating life unnecessarily in this instance.

 

[steph Arnott]

I used the switch state example so the OP could see what was happening in each state, if i was writing the code for my self i would use one state and switch with a TRUE or FALSE. You mention the touch statrt event, i have not had that issue  in over four years, but saying that it may still happen.

"trickier than they appear to folks first learning to script" i tend to disagree on this example, i certanly undertood it better than useing one state with logic switches, but maybe that was just me as i had never writen any code before. My self it encouraged me to attempt after it was working to learn to write the code into one state. Success and understanding what is hapening i found a far better way to keep going. Getting a script to work was a joy, they may have looked like moron had wrote it but later on i went back rewrote bits using say a loop instead of 50 lines of move 0.2, sleep move 0.2, sleep. Walk first, run later was my ethos.

[steph Arnott]

I was just thinking, i think i would be more inclined to use a phantom transparent cube that is collision triggered rather than touch. Walk to ward door, thru the collision prim then door opens, exit the colision prin  door closes. Just a thought. Any how a futer idea, not really relevent now as it would complicate things.



[Nova Convair]

Steph gave a good script example to start with.

Just use llSetPrimitiveParams to switch between PRIM_PHYSICS_SHAPE_CONVEX and PRIM_PHYSICS_SHAPE_NONE and set transparency and glow in the call.

Phantom is something from the past and will switch the whole linkset so will prevent the doors beeing linked. Ignore it.

If you switch the state always use touch_end instead of touch_start. The state change will kill all listens and you need to think how your timers are supposed to work. But for this simple script this is not important.

 

[steph Arnott]

Was not aware of this "PRIM_PHYSICS_SHAPE_NONE" usefull to know.

ADDED, HMM, read the details, appears it can not detect colisions from agents, this true?

[Rolig Loon]

Yes, that's true.  Setting Physics Shape Type to NONE has the same effect as setting the object to phantom, in that it tells the physics engine to ignore any collisions with the object.  It's not exactly the same thing as phantom because the physics download weight is calculated differently, but for this particular application, it works the same way.

[steph Arnott]

so how do you detect the colision event?

volume detect?

[Rolig Loon]

I believe so, but I can't recall having needed to do that myself.  Try it.

[steph Arnott]

Will try it out, thanks

[Nova Convair]

A volumedetect prim works fine, I have used that a while ago. It makes the prim phantom but detects collisions of physical objects and avatars. Works only in root - don't link it - it's contagious and will switch the whole object.

 

[steph Arnott]

Will mess around with it when i get in world. can allways archive the script for later applications. Will see how it goes. Thanks for the info.

[Innula Zenovka]

---

steph Arnott wrote:

so how do you detect the colision event?

volume detect?

---

As I understand the logic of what the OP wants to do, the door detects the collision while it's in its solid state.   It then turns phantom until the owner (or a timer) turns it solid again.

 

[steph Arnott]

moved past the original OP.. The OP had an answer on page one.

[MishkaKatyusha]

i never thought of using a timer instead of a poke on/poke off state change

 

is it possible to program both a timer and a touch response?

[steph Arnott]

Yes, you just invoke the timer in the touch event

[Innula Zenovka]

---

steph Arnott wrote:

moved past the original OP.. The OP had an answer on page one.

---

OK.  In that case, then, I'm unclear what process we're trying to model.  

If we want to detect collisions in an object you can walk through, we need -- as you know -- to use llVolumeDetect.   That has to apply to the whole linkset, unlike PRIM_PHYSICS_SHAPE_NONE, which can be applied to individual linked prims.   This may or may not be a problem.

Be that as it may, someone walks into the llVolumeDetect prim -- what do you want to happen next?

[steph Arnott]

it started with a touch open then touch close. I said maybe be better to have a colision event that after the non colision would invoke cliosed which went  to prim params as i still stuck in the old age of phantom prims.My fault,  EDITED FOR TYPO